I call tragedy a 'Cassandra Object Abstraction' (COA), because I try write a reusable implementation of patterns that are commonly used for cassandra data modeling. E.g. using TimeUUID columns for storing an Index is a pattern. Then various strategies to partition these Indexes are another pattern.
I'm hoping that after some iteration a good mix of high-level abstractions that can be reused for all kinds of apps will emerge. It feels ambitious to me to try to implement cross-nosql-store abstractions before these patterns and best practices have been documented and battle-proven. On that note, if such documentation does exist, or you know cool patterns, i'd love to hear about them! Paul On Mon, Apr 26, 2010 at 10:46 AM, banks <bankse...@gmail.com> wrote: > The real tragedy is that we have not created a new acronym for this yet... > > OKVM... it makes more sense... > > > On Mon, Apr 26, 2010 at 10:35 AM, Ethan Rowe <et...@endpoint.com> wrote: >> >> On 04/26/2010 01:26 PM, Isaac Arias wrote: >>> >>> On Apr 26, 2010, at 12:13 PM, Geoffry Roberts wrote: >>> >>> >>>> >>>> Clearly Cassandra is not an RDBMS. The intent of my Hibernate >>>> reference was to be more lyrical. Sorry if that didn't come through. >>>> >>> >>> >>>> >>>> Nonetheless, the need remains to relieve ourselves from excessive >>>> boilerplate coding. >>>> >>> >>> I agree with eliminating boilerplate code. Chris Shorrock wrote a >>> simple object mapper in Scala for his Cascal Cassandra client. You may >>> want to check out the wiki on GitHub >>> (http://wiki.github.com/shorrockin/cascal/). >>> >>> In my opinion, a mapping solution for Cassandra should be more like a >>> Template. Something that helps map (back and forth) rows to objects, >>> columns to properties, etc. Since the data model can vary so much >>> depending on data access patters, any overly structured approach that >>> prescribes a particular schema will be of limited use. >>> >> >> For what it's worth, this is exactly my opinion after looking at the >> problem for a bit, and I'm actively developing such a solution in Ruby. I >> spent some time playing with the CassandraObject project, but felt that >> despite all the good work that went in there, it didn't feel to me like it >> fit the problem space in an idiomatic manner. No criticism intended there; >> it seems to lean a little more towards a very structured schema, with less >> flexibility for things like collection attributes the members of which all >> have a key that matches a pattern (which is a use case we have). >> >> So, for my approach, there's one project that gives metaprogramming >> semantics for building the mapping behavior you describe: build classes that >> are oriented towards mapping between simple JSON-like structures and >> full-blown business objects. And a separate project that layers Cassandra >> specifics on top of that underlying mapper tool. >> >> The rub being: it's for a client, and we're collectively sorting out the >> details for releasing the code in some useful, public manner. But hopefully >> I'll get something useful out there for potential Ruby enthusiasts before >> too long. Hopefully a week or two. >> >> Thanks. >> - Ethan >> >> -- >> Ethan Rowe >> End Point Corporation >> et...@endpoint.com >> > >
