That assumes a consistent conflict resolution strategy for all objects in the bucket (which makes sense under most circumstances I suppose).
I personally like the statebox approach, but you can't please everyone and it doesn't apply to all possible situations. On the down side that kind of implementation ends up pushing 'code' into your data objects (the allowed operations). For simplicity's sake, I'd leave out conflict resolution until the rest of the code is done :) Cheers, Mark On Wed, Sep 14, 2011 at 1:42 PM, Kev Burns <[email protected]> wrote: > agree on optional read-before-write. > good note on optional returnbody. > > I recall a talk by Yammer about their use of Riak in Scala and the gist was > that they achieve retry using closures. > I has envisioned resolvers as being bucket specific and being automatically > called at read time if present before bubbling a 300 to the code operating > the client. > > $bucket->resolver = function($a, $b) use ($bucket) { > // Try to resolve > return $whether_resolved; > } > > - Kev > c: +001 (650) 521-7791 > > > > On Wed, Sep 14, 2011 at 8:31 AM, Mark Steele <[email protected]>wrote: > >> Looks great! >> >> We are currently still using the 5.2 series, but a better client that only >> supports 5.3 might motivate us to upgrade. >> >> I would just add to make any read-before-write stuff optional (for >> performance reasons), same with returnbody behaviors. >> >> Sibling resolution is very application specific. Not sure how to approach >> that one unless you encapsulate the data payload somehow (like this: >> http://labs.mochimedia.com/archive/2011/05/08/statebox/). Even so, that >> locks you into one approach which may not fit all types of applications. I'd >> love to see statebox-like code baked in though. >> >> We usually do all of our conflict resolution at read time (using an >> approach similar to statebox) whenever an object is returned with siblings. >> >> Cheers >> >> Mark >> >> On Wed, Sep 14, 2011 at 10:23 AM, Kev Burns <[email protected]> wrote: >> >>> >>> Riak 1.0 is coming soon. >>> Now would be a good time to overhaul the PHP client. >>> >>> Goals >>> >>> - Add support for Protocol Buffers >>> - Add support for new Riak 1.0 features (2i, pr, pw, client_id, etc) >>> - Add performance benchmarks >>> - Improve network performance >>> - Improve tests >>> - Add support for streaming results >>> - Add automatic read-before-write >>> - Add support for retries and sibling resolution >>> - Discourage expensive operations by throwing warnings >>> >>> I also think it's time the client required PHP 5.3+ >>> >>> - Namespacing for better class organization >>> - Late static binding for looser coupling and greater extensibility >>> - Anonymous functions for inline retries and sibling resolution >>> >>> Is there anyone using PHP 5.2 in production with Riak that hasn't >>> upgraded to PHP 5.3? >>> >>> >>> - Kev >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >> >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
