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 > >
