Complaints about losing old likes

[KeithG]

I still want my money back!

 

[Dsix36]

I still want my money back!

dislike

 

[kelemvor]

Is there any way to set the "post thanks / like" button on the left to expand by default?

 

[Subcooled]

… For the likes... unfortunately, they were part of the old plugin which is horribly outdated, the company who made it is out of business, and was a security vulnerability for ScubaBoard…

Plugins usually store their data in an SQL-database. This database can be accessed, and SQL can be used to modify, extract and export data. This data can be easily converted and imported into a new database. In all probability, it would have been enough to just disable the old plugin, and then to do a field to field copy (perhaps between two tables) - a pure database operation. I am pretty sure that there was a table with post ids and a set of user ids.

Performing operations like these should be the basic skill of any professional database administrator. Especially in a commercial setting. I am sure there are a bunch of DBAs here on the forum...

OK, don't attempt this on a live database without some experience. These things should be attempted on an offline copy first.

You have kept a database backup, haven't you?

Webhotels and such usually even offer a tool for direct database access. The forum application might not have this functionality built-in, but the webhotel admin panel or the servers admin tools might. phpmyadmin is one such tool for MySql databases.

---------- Post added January 19th, 2015 at 09:51 AM ----------

Some users lost their likes, but more relevantly all the posts lost their likes. The only quality indicator of old posts is gone, and an awfull lot of really valuable information is lost. A "most liked posts" -index could have been used as a basis for more efficient searches, or something. It would costs a million dollars to have someone do the assessment job to give you a competitive advantage like that. Ever wondered how Google or Facebook can finance their operations? Information is money.
Oh well... my coffee is getting cold...

 

[descent]

... In all probability it would have been enough to ... do a field to field copy (perhaps between two tables), a pure database operation. I am pretty sure that there was a table with post ids and a set of user ids.

Good summary!

I prefer to dump the old data and QA it for awhile before reloading it, but yes, that is how it is done.

Performing operations like these should be the basic skill of any professional database administrator. Especially in a commercial setting. I am sure there are a bunch of DBAs here on the forum...

Hah! It should be a basic skill. You should meet some of the programmers and DBAs I have interviewed.

:facepalm9999:

If there is a full database dump from a time shortly before the plugin was decommissioned, it might take a few minutes to copy the dumpfile, select the post_id of every post with one or more "likes", ordered by the user_id of the "liking user", and ouput those columns as CSV or more-generic SQL.

This dumpfile would give you a graph of all of the like counts, likers and (indirectly) the likees.

Presumably, you could rescue lost likes from any number of abandoned like-systems, limited only by the availability of old backups and the patience of the data spelunker.

Big dumps like these can be spot-checked in Excel, which has some excellent tools, but I prefer to write my own data-specific tests each time. In this case, for example, if any liked posts no longer exist (deleted, corrupted, moved, renamed, missing, whatever), it is better to consider not importing a reference to nonexistent data. Similarly, some users may have been banned and had their user_id reassigned later, etc. A larger userbase should demand greater care in this QA step, even if the entire import can be run inside of a transaction and backed out if it doesn't work.

After the data QAs OK, then someone has to study the new "like" system to see if there is a clean, one-to-one mapping of the old relationships onto the new relationships. "Liking" is such a simple concept that any code implementing it is usually readable by ordinary humans. Unless there is some disgusting hairball in the code that maps user_ids to liked_posts, finding precise relationship logic takes anywhere from ten seconds to an hour.

A test account using the new like system can be prodded with command line tools (one bogus like at a time) to map and unmap experimental likes until everyone on the team feels that the logic is sound. With judicious use of safe SQL, this can be done during working hours while the site is live, but many site operators prefer to wait until a scheduled downtime.

Once a valid import path exists, the old likes can be loaded from their most recent backup file during a maintenance window, while the application is offline, and inserted in a minute or two on a fast machine.

If the result is undesirable, the changes can be tossed or postponed. If something really odd has happened, the entire database can be discarded and reloaded from a recent backup in ten or twenty minutes (usually).

Some users lost their likes, but more relevantly all the posts lost their likes. The only quality indicator of old posts is gone, and an awfull lot of really valuable information is lost. ...

Yes, losing the old likes is really not an ideal outcome.

But I am willing to bet that the data is just hiding. I doubt that it's gone forever.

It would costs a million dollars to have someone do the assessment job to give you a competitive advantage like [a "most liked posts" -index].

An index like that is a really nice idea. On big gaming web sites, they are called leaderboards. They are updated continuously. For a forum site, recalculating a top ten list to show "the posts with the most likes" could happen every five minutes or so. Simple code, fun to write.

Large corporation, fat checkbook? Keep adding zeroes. The bureaucracy, the sluggish thinking and the inevitable aggravation demand it. For large enough sites, the ROI is there. The data really is gold and they should pay you dearly to unlock it.

For a small, family-owned site? Some air fills or a boat ride should be more than enough.

 

[chillyinCanada]

Isn't it enough that we have healthy enough egos to like ourselves.

What a bunch of cry babies. It is what it is. Move on.

 

[Jim Lapenta]

It wasn't just about ego. I used those counts for information related to my writing, gear sales, and training business. I added a chapter and several item in others to the outline of my next book based on those counts. What products to bring in and stock were sometimes based on that information. The additions I make to my training courses were often considered with the feedback I got from those.

I felt like as business sponsor I was paying for that info. I don't have the resources to pay another entity for the information I got from those likes. Getting a snarky response to concerns about losing that resource is also not good business. But in some cases based on past history it's not unexpected.

 

[descent]

... the security of this website and everyone's computers who uses this site is more important than some status count.

The focus on security is nice, and appreciated.

But the two things you mentioned are not inseparable. In fact, they're not even related.

 

[HowardE]

Crisis is over. I wrote a conversion script. Enjoy or not.

 

[The Chairman]

Jim, I'm sorry if you perceived my answers as being snarky. We're really trying to do our best as well as what's best for the entire community. It's not easy to please everyone and keep the site running smoothly at the same time. We can only use the tools that are available to us at this time and that function properly.