Yehuda Katz wrote:
However, it feels like the BEST option would be to add a standard database
trigger and let the database handle it without the potential for problems.
Perhaps this is a case for supporting arbitrary options and letting the
adapters generate the appropriate SQL. So:
It might be interesting to use Merb's run_later facilities to asynchronously
update the counter cache on a periodic basis (or only if something was added
to a queue).
However, it feels like the BEST option would be to add a standard database
trigger and let the database handle it without the
There's no reason to ever change a counter_cache after_save. You need
a combination of several hooks (after_create, after_delete, etc).
Having it abstracted seems greatly preferred. Even with these hooks,
the count would often go out of sync so I had an update_cache method
that would synchronize
