-
Notifications
You must be signed in to change notification settings - Fork 12
Make changes a flat list, or add ordering numbers #28
Comments
@daleharvey @nolanlawson @arthurhsu Would any of you want this feature? We currently have per-object-store ordering, but you cannot reproduce the ordering of the whole transaction. I'm trying to figure out if people need this at all. |
As long as each notification contain changes from one and only one transaction, and change of record is not duplicated, the order does not matter for Lovefield. Change of record means that record A added to store S1 will be notified to subscriber as modified record A added to store S1 then the order does not matter The subscriber may need to replay the changes in its own cache, and this replay has to be deterministic and doable. |
Awesome, thanks. You can replay the changes on a per-object-store level, so that would give you: S1: A added, A deleted |
In issue #27 there was a request for allowing the developer to figure out the order of changes across object stores. Since the changes are stored in a
Map<String, Array<Change>>
style, we only see the ordering on a per-object-store basis.This would either be done by flattening the changes (and including the object store name per change), or by including some sort of number that could order them.
I'm fine with flattening. Anyone else pro/against?
The text was updated successfully, but these errors were encountered: