6 ms·
> but this seems to have a high probability of causing deleted items to reappear in a set when nodes come back online. Basically there is no right way to do th
by antirez 14y ago
> but this seems to have a high probability of causing deleted items to reappear in a set when nodes come back online.
Basically there is no right way to do this, it depends on what the application goal is. For instance Dynamo queries the application in this case, so the application can merge things if needed, intersect things otherwise, and so forth.
For Sets the union was picked in order to guarantee safety. For instance if you model a shopping cart this way, and there is a net split where a client gets into a minority partition and writes a new item (as the user put a new item in the shopping cart during the partition), if you do union on merge the user will still have the item.
In other applications of course the side effect of this (resurrection of deleted items) is not a good idea, but there are different ways to deal with it. For instance in the case of the shopping cart, this can be made more resistent by adding special items that mark old items as deleted, letting the application displaying only the right thing.
- rdtsc 14y agoHow about providing the ability to set merge handlers in Lua for different data types / keys? Or if there are 3 different and well known strategies, somehow let users pick one and set it as a default. If not let users run Lua scripts that will be executed to resolve conflicts in a custom way. I do this for CouchDB, it has a very convenient changes feed that can also stream conflicts when they appear. So there is a custom (and separate) conflict resolver process that resolves conflicts in an application specific way. For consistency though you'd need a way to run those synchronously somehow as soon as you detect the conflict.