Test case for broken counter caches

[howardr]

Counter caches are not updating correctly after a child association is restored. If I try to fix this in the model by using an after_restore hook, then a different test case breaks.

[howardr]

Specifically this one is broken right now.

<1> expected but was
<0>.

[radar]

@howardr Thanks for the test to reproduce the issue. Have you had any luck with fixing it yet?

[bluej100]

@radar : What would you think of triggering after_create as well as after_restore when restoring? I feel like it is generally equivalent to a creation. I'm seeing the same counters issue with https://github.com/magnusvk/counter_culture .

[radar]

No, I think that's a bad approach. The record is not created. It is only restored. Please investigate an alternativez

[bluej100]

I disagree. Restoring is a type of creation, as it adds a new record
matching a previously deleted record to the default scope. It is the
opposite of destroy. It introduces a new record which matches a deleted
record. In my opinion, the fact that this gem keeps rows of deleted records
in the same table should be thought of as an implementation detail: they
could just as well be kept in parallel archive tables.

If this gem is to interoperate with others that don't have a concept of
soft deletion, I think triggering a create event is the best solution.
On Nov 20, 2014 10:50 PM, "Ryan Bigg" notifications@github.com wrote:

No, I think that's a bad approach. The record is not created. It is only
restored. Please investigate an alternativez

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

[BenMorganIO]

I think @excid3 just fixed this. Let me know if I'm at error :)