search

WICG / indexed-db-observers

Prototyping and discussion around indexeddb observers.
Other
85 stars 12 forks source link

Make changes a flat list, or add ordering numbers #28

Open dmurph opened 8 years ago

dmurph commented 8 years ago

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?

dmurph commented 8 years ago

@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.

arthurhsu commented 8 years ago

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 record A deleted from store S1 record A added to store S2 record A modified

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.

dmurph commented 8 years ago

Awesome, thanks. You can replay the changes on a per-object-store level, so that would give you:

S1: A added, A deleted S2: A added, A modified