Multi-level counter-cache following similar path seem to affect each other about counter_culture HOT 6 CLOSED

Interesting; if I understand this correctly, the counter cache incrementing / decrementing itself works correctly for this, just the counter_culture_fix_counts call doesn't? That's at least the behavior I would expect -- the increment / decrement queries are atomical and incremental, thus should build on top of each other. But the fix_counts is not designed to take into account the possibility that there are multiple different counter_culture statements that write to the same column. I wouldn't be opposed to adding this if you can come up with a pull request, though the logic in fix_counts is becoming increasingly complex, so I do not know how feasible that would be.

In all honesty, I would advise you to just avoid using fix_counts here. Do use counter_culture for the incrementing / decrementing -- it should work fine for that -- but just roll your own simple fix-up script using find_each. It's not as fast as using counter_culture's database-level fixing but unless your accounts table is huge, that really shouldn't be a problem.

Closing, as I won't have the time to address this myself. But again, very happy to look at a PR.

from counter_culture.

Thanks, Magnus!

from counter_culture.

Hi Magnus

I was digging through the docs for counter_culture, because I thought I saw a way to move counters to a different table. I don’t see that info in the docs anymore and wanted to check with you to see if counter_culture has a way of pointing the counter cache to a different table (not the one named after the model the counter_culture method call is in).

Thanks

Adam

Adam Stockland

On Jun 9, 2014, at 7:10 PM, Magnus von Koeller [email protected] wrote:

Closed #55.

—
Reply to this email directly or view it on GitHub.

from counter_culture.

The counter cache column is not on the model where you put the counter_culture call, it's on the association that you specify there. You can see that in the simple example here: The counter_cache call is in Product but the cache column is in the categories table. You can take that further with multi-level counter-caches. Note, however, that the behavior there changes, also, as the counter-cache gets aggregated over the entire hierarchy.

from counter_culture.

Sorry, I didn't do a good job at wording my email. I'm looking to move the
counters into a third, counter dedicated, model.

Adam

On Tuesday, July 22, 2014, Magnus von Koeller [email protected]
wrote:

The counter cache column is not on the model where you put the
counter_culture call, it's on the association that you specify there. You
can see that in the simple example here
https://github.com/magnusvk/counter_culture#simple-counter-cache: The
counter_cache call is in Product but the cache column is in the categories
table. You can take that further with multi-level counter-caches
https://github.com/magnusvk/counter_culture#multi-level-counter-cache.
Note, however, that the behavior there changes, also, as the counter-cache
gets aggregated over the entire hierarchy.

—
Reply to this email directly or view it on GitHub
#55 (comment)
.

from counter_culture.

So I'm not quite clear what the use-case here would be, so I'm not entirely sure how to answer your question. But if there was another model that had a 1:1 mapping with your dependent model, you should be able to use multi-level counter-caches to move your counter cache there. Is that what you mean?

from counter_culture.