On 04/26/2010 03:11 PM, Tatu Saloranta wrote:
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.
Right. Additionally, this mapping layer between "simple" (i.e.
JSON-ready) structures and "complex" (i.e. business objects) would seem
to be of much more general value than a Cassandra-specific mapper. I
would think most any environment with a heavy reliance on Thrift
services would benefit from such tools.
--
Ethan Rowe
End Point Corporation
et...@endpoint.com
