Justin, It sounds like your specific needs _might_ be possible with application logic, but be aware that Riak is an eventually consistent database. There are many subtleties to this type of coordination. You will need read-your-writes consistency, which means R + W > N. I would recommend the following resources:
http://wiki.basho.com/Eventual-Consistency.html http://www.allthingsdistributed.com/2008/12/eventually_consistent.html Terminology-wise, you should also know that there is no way to atomically update more than one replica (much less multiple keys) in Riak. This is one of the tradeoffs for high availability in a distributed system. On Sat, Oct 29, 2011 at 1:46 PM, Jeremiah Peschka < [email protected]> wrote: > I'm just assuming that my implementation might be naive. > > As far as the tedious label goes, as your application's functionality grows > in complexity, you may find it tedious to manage the complexity of manually > handling transactional rollback in a distributed system. > > Managing relationships using links has some maintenance overhead in Riak > because of the nature of handling this sort of situation. > > But, all in all, it's probably not terrible as long as you decrease the > number of relationships in the application by saving related objects within > the same collection. > --- > Jeremiah Peschka - Founder, Brent Ozar PLF, LLC > Microsoft SQL Server MVP > > On Oct 29, 2011, at 10:32 AM, Justin Karneges wrote: > > > On Saturday, October 29, 2011 08:42:52 AM Jeremiah Peschka wrote: > >> 1) Use an RDBMS. Since you're here, I'm guessing that you're already > using > >> Riak or else that Riak has qualities that you want for your application. > > > > Right. This is early on in the app's lifetime and the data storage is > not > > terribly complicated. I just need some parent/child relationships and > when I > > saw the Links feature I figured this was an expected usage of Riak. > > > >> 2) As Alex suggests, you can implement this in your application. > > > > Yes, this I am ready for. As I understand it, using Riak successfully > > generally means designing your application with its limitations in mind. > So, > > let's go write some funky app code! > > > >> This could also be difficult: the application must be aware of activity > going > >> on with objects in your database AND be able to roll them back. In > >> pseudocode you'd do this: > >> > >> orig = Riak.get('whatevs') > >> child = new Child(orig) > >> > >> > >> if Riak.put(child) > >> if !Riak.link(orig, child) > >> Riak.delete(child) > >> // error up the stack > >> else > >> // we don't care, the child didn't save. error up the stack > >> > >> This is probably naive and is definitely tedious, even if you do > implement > >> your own application layer to handle read/write operations. > > > > See, to me, this looks exactly like what you're supposed to do. How is > it > > naive and tedious? I would assume that everyone writing a serious app > with > > Riak has to do things like this. > > > > Justin > > > > _______________________________________________ > > 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 >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
