It is possible that strategy: sql is the culprit here.
There is also probably a problem around cache depth too.
The increase_parent_counter_cache callback is not consistent with the decrease_parent_counter_cache or the udpate
some ideas on making them consistent and fixing the problem
update parent_counter_cache to respects @_trigger_update_callback
drop @_trigger_delete_callback (are these unnecessary internals?)
Not sure if update follows the same rules as destroy introduced in 63b42f53 But would like both trees to follow the same logic
There are reports of incorrect cache counts. So when insert and destroy have different guard clauses, it is suspect.
I admit that I am not totally familiar to the core use case so I will need to more into why this was introduced in #307 - trying to resolve #584 (and may be able to provide advice for #586 )
TODO:
introduce tests that corrupt the counter caches see #584 (and mildly related: #586 )
introduce test with rollback
introduce STI parents for test (parent should be parent class and child node should be a child class of the parent)
see if we can use REPLACE instead of REGEX_REPLACE. regex buys us anchoring at the beginning of the line (which is needed if we want to support materialized_path), but REPLACE buys us binary support.
Counter caches get corrupted.
It is possible that strategy: sql is the culprit here. There is also probably a problem around cache depth too.
The
increase_parent_counter_cache
callback is not consistent with thedecrease_parent_counter_cache
or the udpatesome ideas on making them consistent and fixing the problem
@_trigger_delete_callback
(are these unnecessary internals?)Not sure if update follows the same rules as destroy introduced in 63b42f53 But would like both trees to follow the same logic
There are reports of incorrect cache counts. So when insert and destroy have different guard clauses, it is suspect.
I admit that I am not totally familiar to the core use case so I will need to more into why this was introduced in #307 - trying to resolve #584 (and may be able to provide advice for #586 )
TODO: