Hi Sean, Another question, for the User object in the described scenario, would CRDT set still be required?
Say, if an user clicked like and unlike multiple times in a short period of time, is it correct in saying that two riak nodes could potentially be updating the same User object in an non deterministic order ? Thanks Regards, Jimmy. On Sun, Mar 3, 2013 at 3:54 PM, Sean Cribbs <[email protected]> wrote: > Hi Jimmy, > > Sorry for taking this off-list; I meant to reply-all on that message! > Anyway, we do have a work-in-progress CRDT integration and we hope to > have it production-ready later this year. > > On Sun, Mar 3, 2013 at 9:02 AM, Jimmy Ho <[email protected]> wrote: > > Hi Sean, > > > > Thanks for the quick response. > > All makes good sense. > > > > Am using python, found this on git hub which seems to do what I need > (will > > need to test it further) > > > > https://github.com/ericmoritz/riak_crdt > > > > Any future plans to built CRDT features into Riak, or is it something > > believed to sit more at the client side to implement merging/conflict > > resolution? > > > > Thanks for the help. > > Regards, > > Jimmy > > > > On Sat, Mar 2, 2013 at 8:57 PM, Sean Cribbs <[email protected]> wrote: > >> > >> Jimmy, > >> > >> Links are going to quickly become difficult to manage. > >> > >> This is the perfect problem for a CRDT, probably an OR-set. The nice > >> thing about CRDTs is that even when multiple writers are involved, > >> there's a single way to merge conflicts which always moves toward the > >> real value (monotonic). When someone clicks the "like button", you > >> would add their user ID to the set. (Assuming they can un-like, you > >> would remove them from the set when they do that.) You would probably > >> do something similar for the other direction, the user's list of post > >> -- but is easy to manage from the concurrent-writes standpoint, since > >> a user is probably the only one modifying that. If you never need to > >> "un-like", then the set only grows and is thus simpler to put > >> together. > >> > >> Unfortunately, the CRDT support built into Riak is somewhat limited > >> right now. You would need to implement the convergent set yourself, or > >> use an existing client-side library. Here are a few: > >> > >> * Knockbox (Clojure) https://github.com/reiddraper/knockbox > >> * Statebox (Erlang) https://github.com/mochi/statebox > >> > >> A quick search on Github will find you a lot of other options, too (in > >> various states of completion). > >> > >> On Sat, Mar 2, 2013 at 2:10 PM, Jimmy Ho <[email protected]> wrote: > >> > Hi guys, > >> > > >> > Am currently designing the data schema for an application; I have a > >> > question > >> > hoping some of you could help. Thanks in advance. > >> > > >> > One of the functionalities is a 'like button' to posts > >> > > >> > Each post is stored as an object in Riak, eg /post/<id> > >> > > >> > To like a post, I am planning on creating a link from user object to > the > >> > post object, and the reverse direction, such that it would be easier > to > >> > link-walk/mapreduce. > >> > > >> > My question is, if a particular post is very very popular, and > everyone > >> > is > >> > pressing 'like'. Would the write requests (to the post's object > >> > header) > >> > conflict each other? > >> > > >> > Is the above a bad schema design from that perspective? Any > suggestion > >> > of a > >> > better design? > >> > > >> > Thanks. > >> > Regards, Jimmy > >> > > >> > _______________________________________________ > >> > riak-users mailing list > >> > [email protected] > >> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >> > > >> > >> > >> > >> -- > >> Sean Cribbs <[email protected]> > >> Software Engineer > >> Basho Technologies, Inc. > >> http://basho.com/ > > > > > > > > -- > Sean Cribbs <[email protected]> > Software Engineer > Basho Technologies, Inc. > http://basho.com/ >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
