On Thu, Jun 16, 2011 at 08:40:45AM -0700, Greg Nelson wrote:
> Well, it is kind of Riak specific. An implementation that treated DELETEs
> like PUTs (tombstones w/ vector clocks for ordering), then this would not be
> an issue, right? When no primary nodes are down, the tombstones can be
> physically deleted on the backend. A logical delete could never reappear if
> that were how it worked.
>
> Is this essentially what is on the current master branch (not yet released)?
>
Yes, this is essentially how its supposed to work on master. A tombstone
is put and then an async get is fired off and if the async get finds all
the primary nodes in the preflist are up, it does the delete. If not,
the next time the key is fetched, it does the same check again and will
do the delete then if the downed node is up.
Some issues still remain with this however, specifically how to override
tombstones (since notfounds do not include a vector clock). I've also
added a 'deletedvclock' GET option to change the return behaviour for
when a tombstone is found to instead return {deleted, VClock} so you can
safely override a tombstone, instead of triggering a merge (or creating
siblings).
This isn't perfect and we're discussing better solutions, but it does
make things significantly better.
Andrew
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
