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 <age.mo...@gmail.com> 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 > 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
