lucafavatella
commented
8 years ago 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)).
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 unsaferiakc_pb_socket:delete/3rather thanriakc_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 - callriakc_pb_socket:delete_vclock/4passing 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:
riakc_pb_socket:fetch_typefunction to include an option to return the vclock of the object; orriakc_pb_socket:delete_typeto 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...