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
