Java bits: Horizontal Scalibility and DAO layer design

[Selcuk Bozdag <sb...@gmail.com>]

Hi,

The question I am asking is a bit about the design of a data access
objects layer on top of a cassandra datastore.

I had a look at project Kundera which basically implies JPA approach
by creating POJOs and mapping them through annotations. Looks
promising but what if I would like to have new columns inside the data
store(i.e. an attribute of a pojo class) without changing the
codebase? How could I achieve such an extensiblity on the DAO layer?
What would be the most relevant design pattern?

Please do not take the question regarding Kundera, it was just an
example. The eventual design should let me CRUD POJOs while gaining an
ability to be extended.

Regards,

Selcuk

Re: Java bits: Horizontal Scalibility and DAO layer design

[Peter Tillotson <sl...@yahoo.co.uk>]

I had a quick look at DAO and my common uses case is, row names
appearing as column ID's elsewhere (indexes etc). I also wanted to track
deltas at a column level and have a reasonable sized client side cache.

I ended up with two abastract DAO's, one for Column Family, one for
Super column factory, then subclasses with overridden methods for build
/ deconstruct POJOs.

Managing a bag of columns in this way makes column level locking easy,
and the delta approach minimizes the network traffic.


On 27/07/11 16:15, Selcuk Bozdag wrote:
> Hi,
> 
> The question I am asking is a bit about the design of a data access
> objects layer on top of a cassandra datastore.
> 
> I had a look at project Kundera which basically implies JPA approach
> by creating POJOs and mapping them through annotations. Looks
> promising but what if I would like to have new columns inside the data
> store(i.e. an attribute of a pojo class) without changing the
> codebase? How could I achieve such an extensiblity on the DAO layer?
> What would be the most relevant design pattern?
> 
> Please do not take the question regarding Kundera, it was just an
> example. The eventual design should let me CRUD POJOs while gaining an
> ability to be extended.
> 
> Regards,
> 
> Selcuk
> 

Re: Java bits: Horizontal Scalibility and DAO layer design

[Selcuk Bozdag <sb...@gmail.com>]

Thanks Anthony. Following your comments, I searched for a similar
approach using command pattern. http://code.google.com/p/casemate
seems a way of doing that.

On 27 July 2011 18:23, Ikeda Anthony <an...@gmail.com> wrote:
> Speaking from personal experience (and believe me it all comes down to this) we attempted a DAO approach as well. However, we found that based upon all the mutator.addInsertion()s we were creating across column families everything ended up in the same DAO - we only have 3 main Column Families that represent about 10 logical entities.
>
> So we have now moved to a Command pattern where the mutations are encapsulated within a command which can be used with other commands if need be - though we haven't found a need to just yet.
>
> Anthony
>
>
>
>
> On 27/07/2011, at 08:15 AM, Selcuk Bozdag wrote:
>
>> Hi,
>>
>> The question I am asking is a bit about the design of a data access
>> objects layer on top of a cassandra datastore.
>>
>> I had a look at project Kundera which basically implies JPA approach
>> by creating POJOs and mapping them through annotations. Looks
>> promising but what if I would like to have new columns inside the data
>> store(i.e. an attribute of a pojo class) without changing the
>> codebase? How could I achieve such an extensiblity on the DAO layer?
>> What would be the most relevant design pattern?
>>
>> Please do not take the question regarding Kundera, it was just an
>> example. The eventual design should let me CRUD POJOs while gaining an
>> ability to be extended.
>>
>> Regards,
>>
>> Selcuk
>
>

Re: Java bits: Horizontal Scalibility and DAO layer design

[Ikeda Anthony <an...@gmail.com>]

Speaking from personal experience (and believe me it all comes down to this) we attempted a DAO approach as well. However, we found that based upon all the mutator.addInsertion()s we were creating across column families everything ended up in the same DAO - we only have 3 main Column Families that represent about 10 logical entities.

So we have now moved to a Command pattern where the mutations are encapsulated within a command which can be used with other commands if need be - though we haven't found a need to just yet.

Anthony




On 27/07/2011, at 08:15 AM, Selcuk Bozdag wrote:

> Hi,
> 
> The question I am asking is a bit about the design of a data access
> objects layer on top of a cassandra datastore.
> 
> I had a look at project Kundera which basically implies JPA approach
> by creating POJOs and mapping them through annotations. Looks
> promising but what if I would like to have new columns inside the data
> store(i.e. an attribute of a pojo class) without changing the
> codebase? How could I achieve such an extensiblity on the DAO layer?
> What would be the most relevant design pattern?
> 
> Please do not take the question regarding Kundera, it was just an
> example. The eventual design should let me CRUD POJOs while gaining an
> ability to be extended.
> 
> Regards,
> 
> Selcuk