Pat Allan on 13 May, 2020 04:44 AM
I'm going to ponder this one a bit more, nothing comes to mind immediately… but I do wonder if it's related to merges, as that's not a piece of functionality I've ever used myself in my own apps, so I'm less familiar with the edge cases.
I don't suppose you're able to reproduce the issue locally?
It doesn't seem to, however I wonder the same about merges. Is there a better way to implement a delta setup without using merges? Currently, I have a scheduled job running the merge and assume it is keeping the delta index small and everything running a-ok... ish ;p
Pat Allan on 21 May, 2020 12:55 PM
Some further thoughts about all of this…
I've set up a test app locally with deltas and merging, and thus far, haven't been able to reproduce the issue.
Merges should indeed keep the delta indices small - after each merge, any delta records have their flag set to false, so the next time a record is edited/added, the index will contain only that record (and then further changes until the next merge).
Generally I opt for real-time indices these days instead of SQL-backed indices - this also removes the need for deltas. Is there a reason you've chosen SQL-backed indices? (It's certainly a valid approach in some cases, but I figure it's worth me asking why)
You've mentioned you're using destroy calls when deleting objects - just to confirm, this is destroy on a single record, thus the ActiveRecord callback lifecycle is invoked? (Though, now I think destroy on a relation will still instantiate all of those objects and call destroy on each and invoke callbacks, so maybe it's fine either way)