Thanks Brian What do you think would be the proper way for Riak itself to deal with case 1? Should it return a 200 with an empty body and the X-Riak-Deleted header?
Could you give me an example of a use case for reproducing case 1 in a unit test? Case 2a is easy but I've tried several ways to reliably produce case 1 and I'm not getting anywhere. Do you have an idea of how many people actually use the option to "return deleted vclocks". My Scala client basically just treats tombstones like completely deleted values, so for case 1 that would lead to "normal" 404 behavior and during conflict resolution it will just ignore/skip tombstones. But if lots of people are interested in dealing with tombstones directly I might have to change that to something similar to what you did in the java client. Are there any plans on adding a documentation section about tombstones and deletes in Riak? I think that would definitely be helpful for other people writing clients. Age On Mar 25, 2013, at 14:29, Brian Roach <[email protected]> wrote: > Hi Age, > > I'm the author of the pull request for the Java client you cite. > There's still inconsistency in how these are returned via the HTTP > protocol. Partially that's my fault in that I didn't open an actual > issue when I discovered the problem I note in my comments. While > reviewing the issue to make sure I answered your question correctly, I > found another. > > As of right now (Riak 1.3), here's what you will find: > > 1) If *only* a tombstone exists when you do a GET for a key, you will > receive a 404 but it will contain the X-Riak-Vclock header (with a > vclock). A "normal" 404 (when there's no object) will not have this > header. > > 2) If there is a set of siblings, and one of them is a tombstone: > > 2a) Retrieving all the siblings at once by including "Accept: > multipart/mixed" in the GET will return all the siblings, and the > tombstone will include the "X-Riak-Deleted: true" header > > 2b) Retrieving each sibling manually by adding ?vtag=XXXXXX to the GET > will (unfortunately) return a 200 OK for the tombstone but it will > have an empty body (Content-Length: 0). > > I'm going to open issues for 1 and 2b just so we get things to be > consistent. That being said, I can't think of a reason you'd ever want > to do 2b so at least the impact there is minimized. For 1 you can > obviously still identify a tombstone the same way I'm doing it in the > Java client -> 404 + vclock = tombstone. > > Thanks, > _ Roach > > On Sun, Mar 24, 2013 at 2:09 PM, Age Mooij <[email protected]> wrote: >> Hi, >> >> I've been trying to find some comprehensive docs on what Riak http clients >> need to do to properly support dealing with tombstone values. I ran into >> tombstones while debugging some unit tests and I was very surprised that the >> Basho (http) API docs don't mention anything about having to deal with them. >> >> It's very hard to find any kind of complete description on when Riak will >> produce tombstone values in http responses and what the proper way of >> dealing with them is. This makes it very hard to write good unit tests and >> to implement the "correct" behaviour for my riak-scala-client. >> >> Can anyone point me towards a comprehensive description of the expected >> behaviour? Or even a description of what most client libraries end up doing? >> >> For now I just ignore siblings with the X-Riak-Deleted header (undocumented >> AFAIK) when resolving conflicts caused by a delete followed by a put (based >> on the same vclock). I'm not sure this header could (or should) occur in any >> other situation. >> >> Here's the online stuff I've found so far: >> >> - A pull request for the java client: >> https://github.com/basho/riak-java-client/pull/195 >> >> - The most important commit message for the above pull request: >> https://github.com/basho/riak-java-client/commit/416a901ff1de8e4eb559db21ac5045078d278e86 >> >> - Some interesting code introduced in that commit: >> >> // There is a bug in Riak where the x-riak-deleted header is not returned >> // with a tombstone on a 404 (x-riak-vclock exists). The following block can >> // be removed once that is fixed >> byte[] body = r.getBody(); >> if (r.getStatusCode() == 404) { >> headers.put(Constants.HDR_DELETED, "true"); >> body = new byte[0]; // otherwise this will be "not found" >> } >> >> That bug apparently still exists… do all clients implement this hack? Should >> they? >> >> - A message to this mailing list from October 2011: >> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/006048.html >> >> Thanks, >> Age >> >> >> >> _______________________________________________ >> riak-users mailing list >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
