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 >
