On 11/02/2011 10:40 AM, Justin Karneges wrote:
Thanks everyone for these replies (and also Aphyr, off-list). It has helped me
confirm my suspicions and sounds like I'm on the right track.
For one of my keys, I am doing sort of a manual "last write wins" by having
the reader sort siblings by timestamp, then by vtag, to deterministically
select the same sibling every time. The reason for keeping the other siblings
around is they may contain the only references to other keys created along
with them. A separate cleanup process can then be sure to delete the referred
keys before removing the siblings. And of course the algorithm used to
determine the winning sibling is shared by both the read function and the
cleanup function.
We do something similar. A feed, for example, stores a list of keys
pointing to feed items. In memory, I store "pending insertion" and
"pending deletion" lists on a feed. At save time, a model callback saves
the items pending insertion, and deletes any pending deletion.
The conflict resolution operator for a feed takes the union of all feed
item keys, sorts them (to keep the most recent X) and truncates the
list--storing all the truncated items in the pending-deletion list. This
isn't perfect, but has acceptable probabilistic bounds for our use case.
--Kyle
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
