Sorry,
didn't see your mail in time. This is essentially what i was talking
about in my other mail.
So all is good then :-).
Cheers,
Nico
Am 16.06.2011 17:53, schrieb Andrew Thompson:
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
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
