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 >
