gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renato Marroquín Mogrovejo <renatoj.marroq...@gmail.com>
Subject Re: Regarding Avro
Date Tue, 21 Aug 2012 04:47:07 GMT
Hi Ed,

I also think it would be a good idea to do this merge first and then
do the Avro upgrade because this doesn't impact many users, it just
adds more functionality to Gora.
I am really interested in having a conversation about Dynamo's
compiler because using a data store in which we are not able to have
such fine grained persistency control has some pros and cons which I
would be happy to discuss. We should start a new thread for that I
Lewis and me have also discussed on how to keep the type structure
coherent and the role of the persistent interface within the
framework, but we have to have all this  I think we should start by
redoing all the avro stuff first but having in mind that now we can
support non-avro based data stores.

2012/8/19 Ed Kohlwey <ekohlwey@gmail.com>:
> I haven't reviewed the Dynamo module, but my initial thought is that it is
> best to merge it first and then do the Avro upgrade, simply because the
> Avro patch is already in need of a significant rebase and I'm going to be
> kind of busy until October.
> Is the idea of the Dynamo compiler to produce Gora types with annotations
> that are specific to one backend? It might be good to start a conversation
> about what strategies can be used to keep the type structure coherent and
> what the role of the persistent interface is in the framework as well as
> what other contracts are inherent in the code generation implementation
> that different backends use. While doing the Avro upgrade I noticed at
> least one place where reflection was being used to access generated fields
> so I think this is an important area to discuss.
> On Aug 16, 2012 7:00 PM, "Lewis John Mcgibbney" <lewis.mcgibbney@gmail.com>
> wrote:
>> Hi Ed,
>> On Thu, Aug 16, 2012 at 12:44 PM, Ed Kohlwey <ekohlwey@gmail.com> wrote:
>> > It was moved so that the compiler can be used to generate the example
>> > classes rather than checking in generated code. Right now this is done
>> > using the maven exec plugin. My goal is to eventually add a
>> > magen-gora-plugin similar to the maven-avro-plugin.
>> >
>> Nice. Renato has also written a compiler for the dynamodb module for
>> creating annotated classes for the (non-avro based) amazon dynamo
>> store.
>> Thinking about getting the Avro upgrade into trunk... or producing a
>> patch which cleanly applies and compiles with trunk I wonder if we can
>> begin to think about a strategy for phasing this in then. Some things
>> on my mind
>> 1) GSoC finishes soon (end of week) the changes we've made to Gora do
>> not really affect the API as such, they just refactor some of the base
>> classes contained within gora-core to make space for webservices. We
>> hope to be able to merge this into trunk (when the time comes around)
>> pretty easily (ahem!!!)
>> 2) As we've previously discussed, the Avro upgrade makes some pretty
>> hefty changes to the API so getting the phasing right is critical.
>> What do you guys want to do about the above? My initial thoughts are
>> to implement the dynamodb module (if and once we have agreed upon it
>> and when the project actually finishes) before moving on the the Avro
>> upgrade. As dynamodb store is non-avro based the knock-on effect to
>> the Avro work you have done Ed will hopefully be minimal... if we do
>> it tho other way around then the repercussions will probably be more
>> for us to factor into the dynamodb branch before being in a position
>> to merge into trunk.
>> ?
>> Thank you
>> Lewis

View raw message