cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bohm <boh...@gmail.com>
Subject Re: ORM in Cassandra?
Date Mon, 26 Apr 2010 22:44:15 GMT
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 <banksenus@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 <ethan@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
>> ethan@endpoint.com
>>
>
>

Mime
View raw message