basho/riak_core — pull request #402 by jrwest (2013-09-30 19:20:25+00:00)
Title: Proper Bucket Type Creation

Features that plan to use bucket types require that certain properties be "create-only" -- they cannot change after data has been written to buckets under the type. To ensure these semantics it is important that nodes see either no "create-only" properties for a type, or only one version of the "create-only" properties. Since types are stored in Cluster Metadata, the current implementation does not guarantee this. To ensure that it does, we take the following two steps to handle concurrent writers:

1. all writes are serialized through the current claimant
2. to handle the case where the claimant changes over before properties have had a chance to fully propogate, creation is a two step process. Only when all nodes agree can the second step be reached, and nodes do not see the properties (while handling requests, etc) until the second step is complete.

This, also, allows for the "create-only" properties to be changed between the first and second steps, referred to as "creation" and "activation". This is useful in the case where a user accidentally specifies the wrong value for a "create-only" property. After activating the type, all properties that are not "create-only" may continue to be updated. More details can be found in the module edoc for `riak_core_bucket_type`.

riak_core does not enforce the notion of "create-only" types. This PR includes an extension to riak_core's bucket validators (changing the interface to validator modules). Validation functions are now passed an atom indicating if the properties are being validated are for bucket type creation, or are type or bucket properties for updating. In addition, the function is passed the type and bucket, as well as the old properties if they existed. Validators can use this information to enforce "create-only" types.

Lastly, this PR makes a minor change to `riak_core_bucket_props` to use the `max` function in `resolve` -- as suggested somewhere during review of an earlier PR.