Erlang Client: get_update_metadata vs get_metadata

Michael Radford mrad at blorf.com
Tue Jun 12 17:37:32 EDT 2012


Reid,

I do understand why update_metadata exists. I guess what I'm
suggesting is a better default behavior, especially for users who
don't explicitly set any metadata values. (Or even if they do, for
when all the metadatas are equivalent.)

I.e., something like this for riakc_obj:get_update_metadata:

get_update_metadata(#riakc_obj{updatemetadata=UM}=Object) ->
   case UM of
       undefined ->
           try
               get_metadata(Object)
           catch
               throw:no_metadata ->
                   dict:new();
               throw:siblings ->
                   default_resolve_metadatas(get_metadatas(Object))
           end;
       UM ->
           UM
   end.

default_resolve_metadatas(Ms = [M | _]) ->
   UniqueWritten = lists:usort([ [KV || KV = {K, _V} <- dict:to_list(M),
                                        K =/= ?MD_LASTMOD,
                                        K =/= ?MD_INDEX
                                 || M <- Ms ]),
   case UniqueWritten of
     [_]        -> M;
     [_, _ | _] -> throw(siblings)
   end.

Mike

On Tue, Jun 12, 2012 at 1:18 PM, Reid Draper <reiddraper at gmail.com> wrote:
>
> On Jun 12, 2012, at 2:56 PM, Michael Radford wrote:
>
>> get_metadata returns the metadata that was read from riak. But if
>> allow_mult is true, and there is more than one sibling, then
>> get_metadata throws the exception 'siblings'. You have to call
>> get_metadatas to get a list with metadata for each sibling in that
>> case.
>>
>> get_update_metadata returns the metadata that is to be written for the
>> object (if you were to call riakc_pb_socket:put at that point). The
>> update metadata is either a single value set explicitly with
>> riakc_obj:update_metadata, or if none was set, and there is only one
>> sibling, then the default is the value of get_metadata.
>>
>> A related question: if I'm not using any user-specified metadata at
>> all, but I do have allow_mult turned on, then how do I choose which
>> metadata to write back to riak after resolving the conflict? Or could
>> I just call update_metadata with an empty dict in that case?
> I'd recommend calling update_metadata with an empty dict. Be sure
> to set the content_type as well.
>>
>> Right now, I have some conflict resolution code that uses the same
>> default strategy as mochimedia's statebox_riak library, which
>> arbitrarily chooses the first metadata. But this seems less than
>> ideal: everything in the metadata is coming from riak, and some of it
>> (e.g., last-modified timestamps) must be ignored when doing the
>> update. So it seems like riak should be able to resolve the "metadata
>> conflict" on its own: just prune all the metadata keys that aren't
>> actually written, and then if the resulting pruned metadatas are
>> identical, then there's no conflict. Or, if there is some reason why
>> the user should prefer one metadata over another, then the client
>> library should give the user some way to decide.
> There are definitely cases where the user wants to choose one metadata
> over another, or perhaps more commonly, "merge" them together, according
> to some conflict resolution semantics. The client provides `update_metadata`
> for this reason. `select_sibling/2` can be used to choose a particular {Metadata, Value}
> pair as well.
>>
>> Mike
>>
>> On Tue, Jun 12, 2012 at 11:25 AM, Andrew Berman <rexxe98 at gmail.com> wrote:
>>> Can someone explain the difference between the get_update_metadata and
>>> get_metadata functions in the Erlang PB Client for Riak?  It's very
>>> confusing...
>>>
>>> Thanks,
>>>
>>> Andrew
>>>
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users at lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>
>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>




More information about the riak-users mailing list