Hi Ed, We are about to commit a patch for this tonight so I will update the goraamazon branch ASAP and get back to you snappy.
Thanks Lewis On Thu, Aug 23, 2012 at 5:35 PM, Ed Kohlwey <[email protected]> wrote: > Sorry, I fell off this thread and just had the presence of mind to come > back to it today. > > Can you post a link to your work on the dynamo compiler? I don't know if > we're on the same page. I'm not familiar with the Dynamo API at all and as > a result I don't think I understand all your comments. > > On Tue, Aug 21, 2012 at 1:00 AM, Renato Marroquín Mogrovejo < > [email protected]> wrote: > >> Sorry, I pressed send while I was rewriting my own email lol >> What I mean is that while doing the avro upgrade we have to do it >> thinking on all the considerations you mentioned Ed i.e. >> - Strategies to keep the type structure coherent >> - Role of the persistent interface within the framework >> - Inherent contracts from code generation. >> But having in mind that Gora can now support data services. >> About the last point, what do you mean by that? Do you mean that we >> will tied in any way to our code generation? >> >> >> Renato M. >> >> 2012/8/20 Renato Marroquín Mogrovejo <[email protected]>: >> > 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 >> > think. >> > 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 <[email protected]>: >> >> 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" < >> [email protected]> >> >> wrote: >> >> >> >>> Hi Ed, >> >>> >> >>> On Thu, Aug 16, 2012 at 12:44 PM, Ed Kohlwey <[email protected]> >> 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 >> >>> >> -- Lewis
