Fixed Likes don't update after username change?

[RastaLulz]

Hello,

I'm not sure if this is a bug, or something that was intended to reduce the amount dynamic data taken from MySQL.

When a user likes a post, then has their username changed, it doesn't seem to update on the post it self.

For example, it shows that Craigypoo liked the post:

Yet when you click his name, it shows his current and up to date username, Sledmore:

 

[Vincent]

This bug is reported quite a few times already.

http://xenforo.com/community/thread...dont-change-if-the-username-is-changed.22775/
http://xenforo.com/community/threads/name-likes-this-does-not-reflect-username-changes.5804/
...

So this is a duplicate and as designed

 

[Kier]

This is working as designed - the names will update next time the content is liked or unliked, but it's simply not practical to go through every content item rebuilding the likes cache whenever a username is altered.

 

[digitalpoint]

This is working as designed - the names will update next time the content is liked or unliked, but it's simply not practical to go through every content item rebuilding the likes cache whenever a username is altered.

Was actually just going to reply with the same thing. The DB would come to a crawl with the nasty full table scan query needed to update the username in realtime for likes... Not unlike how vBulletin poops itself when it gets to the pmtext table when you change a username (assuming you have a lot of PMs in the table of course).

 

[digitalpoint]

Actually, I gave this some more thought... and it could be done without too much nastiness with the database...

Something like this (this is just off the top of my head, so obviously you want want to sanitize variables:

'UPDATE xf_post
SET like_users = REPLACE(like_users, 'i:' . $userId . ';s:8:"username";s:' . strlen($oldUsername) . ':"' . $oldUsername .  '";', 'i:' . $userId . ';s:8:"username";s:' . strlen($newUsername) . ':"' . $newUsername .  '";')
WHERE post_id IN (SELECT content_id FROM xf_liked_content WHERE content_type = 'post' AND like_user_id = $userId)'

Since we already know the exact posts that have a cache that would need to be updated, you can use the sub-query to just do the replace on those records (and not needing to do a full table scan). Even if someone did a ton of likes (like 10,000+ or something), the query should just take a second since it's only looking through the records actually needed.

And triggering a query that might take a second is perfectly fine considering only an admin can change a username anyway (not something the end user can trigger over and over).

 

[Kier]

This has been addressed in XenForo 1.2

 

[CTXMedia]

This has been addressed in XenForo 1.2

Nice one!