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 > >>> >
