Hi Ed, The DynamoDBCompiler can be found at the link below
http://svn.apache.org/repos/asf/gora/branches/goraamazon/gora-dynamodb/src/main/java/org/apache/gora/dynamodb/compiler/GoraDynamoDBCompiler.java I'm looking forward to the discussion which will hopefully follow now as the GSoC project is really in the closing stages. We have a code clean up to do, then one last report and that will hopefully be us ready to submit a patch for the community to review. Thank you and great work Renato. Lewis On Thu, Aug 23, 2012 at 5:38 PM, Lewis John Mcgibbney <[email protected]> wrote: > 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 -- Lewis
