RFC - DO NOT MERGE - Test deletion of object version (i.e. vclock) corresponding to CRDT version (i.e. context)

[lucafavatella]

The riakc_pb_socket:fetch_type/{3,4} function appears not to return the vclock of the Riak KV object hence the user cannot (naively) delete the object at the vclock corresponding to a specific CRDT context being therefore induced to delete the object using the unsafe riakc_pb_socket:delete/3 rather than riakc_pb_socket:delete_vclock/4 - safer as catering for concurrent writes. In order to delete the Riak KV object corresponding to a certain CRDT context the user has the only option of retrieving the server-side representation of the object via mapreduce, compare CRDT contexts (between the one to-be-deleted and the one retrieved server-side) and - if equal - call riakc_pb_socket:delete_vclock/4 passing the retrieved server-side vclock.

This PR adds tests for the above.

I expect this PR not to be merged, as in my opinion it highlights that there is room for improvement in the user API. I would expect either:

• The riakc_pb_socket:fetch_type function to include an option to return the vclock of the object; or
• A new function riakc_pb_socket:delete_type to be added.

I understand both options require changes in the Protocol Buffers messages definition.

I partially understand the complexity in mapping from CRDT context to Riak KV object vclock because in a corner case the Riak object could contain not simply a CRDT e.g. set but unexpected siblings e.g. a set CRDT, a map CRDT, a register CRDT, a non-CRDT (I read of this corner case in the Riak KV server code). But I guess it could be handled returning an error probably as if if happen the user has probably got more serious issues...

---

• Is the understanding behind the comments above wrong?
• Is there already in the API a way for deleting the Riak KV object corresponding to a CRDT context i.e. at a specific vclock?
• If not, how do you envisage the API to evolve in order to cater for this? Your comments are appreciated.

[lucafavatella]

Sample output of relevant tests (not from the Travis CI run of this PR):

    riakc_pb_socket_tests:1369: integration_tests (delete with vclock set with context)...test/riakc_pb_socket_tests.erl:1382:<0.450.0>: The set with context <<131,108,0,0,0,1,104,2,109,0,0,0,8,35,9,254,249,102,157,123,137,97,1,106>> is empty - attempt once to delete the corresponding object. In order to do so, on the server: fetch the latest object by key (mapreduce), assert it has no siblings, assert it stores a CRDT, extract object vclock and CRDT context, finally return to the client. If successfully returned object vclock and CRDT context, on the client: if the CRDT context is the expected one, delete the object specifying the vclock detected as corresponding to the CRDT context.

[0.024 s] ok
    riakc_pb_socket_tests:1395: integration_tests (delete with vclock set with context - case determination of vclock corresponding to context failed for concurrent write)...[0.026 s] ok
    riakc_pb_socket_tests:1430: integration_tests (delete with vclock set with context - case delete failed for concurrent write)...[0.032 s] ok

(I had to comment get preflist test and add redundant and multiple items to hll(set)).

[lucafavatella]

I see that riakc_pb_socket:{modify,update}_type accept options, and I guess one option is return_body, but such option returns the CRDT - not the object. This is also evident in the Protocol Buffers API - ref1 ref2.

So mapreduce looks like the only option currently still.

[lucafavatella]

(It looks like the part that sets up Riak in this PR will soon be obsoleted by #319 - that is good.)

[lucafavatella]

I am currently rebasing this PR on current development code and I plan to open new PR.

• a9ea699 (logging skipped) got merged separately
• Riak setup in Travis CI (781969f and 46e7c02) are now obsolete and I plan to remove
• Allowing mapreduce as string (c071cd9) appears still needed but I will need to find a different way - maybe in https://github.com/basho/riak-client-tools/blob/419dbc5b8a16d56692ef5385e23ed675e289c5b2/lib/riak_cluster_config.bash
  • UPDATE Done in Allow mapreduce function as string riak-client-tools#21
• The actual deletion tests (994ccea) - I will review and maybe refactor a bit

[lucafavatella]

Closing and opening new PR.