After so many years, concurrency problem still exists

[beviz]

article.cached_votes_up => 0

10.times { Thread.new { user.likes article } }

article.cached_votes_up => 2

article.get_up_votes => [{votable_id: 1, voter_id: 1}, { votable_id: 1, voter_id: 1 }]

Fix this issue please!

[davideluque]

I am pretty late here but maybe adapting the Rescue Unique Constraint gem can help.

[ryanto]

Happy to merge any PRs that address this.

[fatkodima]

@ryanto I'm able to implement this. We should change one of the existing db indexes to be unique and rewrite some logic accordingly.

Things to consider:

1. Should we provide a migration for existing apps to change the existing index to be unique?
2. If yes, how much "smart" it should be? 2.1. Should it try to add index concurrently/without locks/etc (for pg is easy, for mysql needs some squats to make it work)? 2.2. If the table already has duplicate data, as mentioned in this issue, should we try to remove it + recalculate some other dependent columns?

Personally, I would prefer adding a basic dumb migration for existing apps, that creates a new unique index, deletes the old index. And we assume, developers should better know how to run this safely on their apps.

[ryanto]

Let's do whatever is simplest. We can release a new breaking version of the gem and in the release notes gives folks a migration that they can copy/paste into their rails app. How does that sound?

[fatkodima]

👍 Breaking version then for sure can drop old rubies/railses too.