Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using outdated counts when running counter_culture_fix_counts? #24

Open
magnusvk opened this issue Sep 20, 2013 · 7 comments
Open

Using outdated counts when running counter_culture_fix_counts? #24

magnusvk opened this issue Sep 20, 2013 · 7 comments
Labels

Comments

@magnusvk
Copy link
Owner

counter_culture_fix_counts first loads all the correct counts into memory, then iterates over all instances and compares counts. Now, if in between loading the correct counts and comparing them in the loop, new children were created or destroyed, this count will be off and reset to an incorrect, outdated value.

Maybe we can use an update_all with a JOIN to let the database handle this atomically? Might this also be faster?

We could also put the fetching of each correct count and the corresponding update into a transaction, but then that would slow the whole process way down.

@magnusvk
Copy link
Owner Author

This problem is much reduced with a927a23; that commit makes sure we pull both the correct and incorrect counts in one query. However, any additions / deletions between then and the later update would still cause a disparity. In any case, we are certainly better off.

@xtagon
Copy link

xtagon commented Oct 5, 2017

Would changing it to do an update_all with a JOIN help out with #79 at all?

Even though that issue was closed, it is actually still a pressing issue for me and I haven't found a suitible solution yet.

@magnusvk
Copy link
Owner Author

magnusvk commented Oct 5, 2017

@xtagon I'm not sure what you mean to be honest.

@xtagon
Copy link

xtagon commented Oct 5, 2017

Maybe we can use an update_all with a JOIN to let the database handle this atomically? Might this also be faster?

@magnusvk I was hoping this meant counter_culture_fix_counts would be faster in that case

@magnusvk
Copy link
Owner Author

magnusvk commented Oct 5, 2017

@xtagon
Copy link

xtagon commented Oct 6, 2017

@magnusvk Yes it does, but it does 1 update_all per primary key, so it's effectively a singular update.

In the end I was able to do a single update_all to compute counts for a table of millions of records in under a minute, but my use case is very simplified compared to what counter_culture supports so I can see how that would be hard to add to the library (with things like soft deletion, advanced associations, etc.)

@magnusvk
Copy link
Owner Author

magnusvk commented Oct 6, 2017

Great, glad you could get it resolved. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants