On Mon, Mar 25, 2013 at 8:05 AM, Age Mooij <[email protected]> wrote: > 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?
Unfortunately this would break the API in regard to backwards compatibility with older versions of Riak. This is not to say we wouldn't ever do that, but it does mean we'd (in general) like to avoid it. I've opened an issue with the suggestion of simply adding the 'X-Riak-Deleted' header for consistency. https://github.com/basho/riak_kv/issues/518 > 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. A tombstone will exist for 3s by default. With the Java client I can reproduce it every time with: IRiakClient client = RiakFactory.httpClient(); Bucket b = client.createBucket("sibling_test").allowSiblings(true).execute(); b.store("key1","value1").execute(); b.delete("key1").execute(); IRiakObject io = b.fetch("key1").returnDeletedVClock(true).execute(); System.out.println(io.isDeleted()); client.shutdown(); > > Do you have an idea of how many people actually use the option to "return > deleted vclocks". Honestly? No, other than "at least two or three" because of interacting directly with them (one of which led to the PR you cited). > 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. Yeah ... it's a hard road trying to guess how people are going to want to use something. Personally? Since the feature exists I'd support it if only for the sake of completeness. > 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. I'll raise that issue this week; there probably should be. In the mean time probably the most comprehensive information on the subject can be found here: http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/006048.html Thanks, _ Roach > 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
