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: >> ... >> 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 ... > 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.
+1 I think proper layering is the way to go: it makes problem (of simple construction of services that use Cassandra as the storage system) much easier to solve, divide and conquer. There are pretty decent OJM/OXM solutions that are mostly orthogonal wrt distributed storage part. I understand that there are some trade-offs (some things are easiest to optimize when Cassandra core handles them), but flexibility and best-tool-for-the-job have their benefits too. -+ Tatu +-
