gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Kohlwey <ekohl...@gmail.com>
Subject Re: Regarding Avro
Date Thu, 23 Aug 2012 16:35:39 GMT
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 <
renatoj.marroquin@gmail.com> 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 <renatoj.marroquin@gmail.com>:
> > 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 <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
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message