Thanks guys,
I'm more inclined to have an API like get_original_metadata and
get_metadata. The get_metadata in this case always returns whatever
metadata is set on the object, new or original. In the current API, if
calling get_update_metadata will return the original metadata if there are
no changes, then I kinda fail to see a use case for the get_metadata call.
Anyone?
Thanks again!
Andrew
On Tue, Jun 12, 2012 at 2:37 PM, Michael Radford <m...@blorf.com> wrote:
> 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 <reiddra...@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 <rexx...@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@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
> >
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
