Erlang Client: get_update_metadata vs get_metadata

Michael Radford mrad at
Tue Jun 12 14:56:30 EDT 2012

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

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?

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.


On Tue, Jun 12, 2012 at 11:25 AM, Andrew Berman <rexxe98 at> 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

More information about the riak-users mailing list