gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
Subject Re: Regarding Avro
Date Thu, 23 Aug 2012 16:38:56 GMT
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 <ekohlwey@gmail.com> 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 <
> 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
>> >>>
>>



-- 
Lewis

Mime
View raw message