Fix counter cache with double destroy, really_destroy, and restore

[excid3]

There's several cases where counter caches get out of sync with soft deletes. This patch gives the ability to disable counter caches for certain events so that the counter caches automatically reflect the correct count.

1. If you destroy a record multiple times, it will decrement the count multiple times.
2. If you soft destroy a record and then permanently destroy it, it will decrement multiple times.
3. Restore does not increment the count.

This checks to see if a record has already been soft deleted when doing a destroy or really_destroy! and then disables the counter cache decrement if it was already soft deleted.

It also adds an increment to the restore method which is the same as the CounterCache create inside ActiveRecord.

Tested this on both Rails 4.2.8 and 5.0.2 and everything looks to be working correctly.

[BenMorganIO]

Looks like Rails 4.1 has become the bane...

NoMethodError: super: no superclass method `each_counter_cached_associations' for #<ParanoidModelWithHasOne:0x00000002628278>

[BenMorganIO]

We could probably update this to:

def each_counter_cached_associations
  !@_disable_counter_cache && defined?(super) ? super : []
end

And add a comment that the defined? super is for Rails 4.1 so that we remember to remove it when we (eventually) drop support for it.

[excid3]

Yeah unfortunately Rails 4.1 doesn't have the same methods. It looks like this got moved from associations to the CounterCache.

I might be able to tweak that method for Rails 4.1 to be compatible with the ways 4.2+ handles it. Gonna take a look at that today.

[excid3]

@BenMorganIO so far the only decent solution I have for this is trying to skip the anonymous callbacks that are added for counter caches in Rails 4.1. It's pretty nasty trying to skip the callbacks though.

filter = self.class._destroy_callbacks.find{ |cb| cb.kind == :before && cb.name == :destroy && cb.raw_filter.source_location.first.include?("belongs_to") }.filter
self.class.skip_callback :destroy, :before, filter, if: ->{ @_disable_counter_cache }

Unfortunately, this is even tougher because if you include Paranoia before the counter cache, this callback won't exist yet to modify... fun fun.

[BenMorganIO]

@excid3 standard style is usually to include Paranoia the very top of their model since it's using a default_scope. Otherwise, all macros are supposed to be at the very bottom. (Yet, that's the style I adhere to, most people probably don't.)

The Rails 4.1 problem is difficult. Can you just an if statement checking if the Rails version is 4.2 or higher? Once Rails 5.1 is out, we can drop support for 4.1.

[excid3]

Yep agreed, I also include at the top as well.

I'm good with that. I've spent a good bit of time on here for 4.1 and with 5.1 around the corner, this is probably the best way to handle it. Let you know when I push up the changes for 4.1 then. 👍

[excid3]

@BenMorganIO alrighty, all done and passed. 🤘

[BenMorganIO]

@excid3 #393

[excid3]

Awesome, thanks for the heads up @BenMorganIO 👍