incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: [VOTE] Gora Graduation Resolution
Date Sun, 18 Dec 2011 18:14:04 GMT
On Dec 18, 2011, at 18:15 PM, Mattmann, Chris A (388J) wrote:
> On Dec 18, 2011, at 3:28 AM, Marcel Offermans wrote:
>> On Dec 18, 2011, at 6:54 AM, Mattmann, Chris A (388J) wrote:
>>> On Dec 17, 2011, at 6:16 PM, Niclas Hedhman wrote:
>>>> I think the Board might have an issue with the 'purpose' of the
>>>> project (I would if I was in the Board). The formulation
>>>> " a Project Management Committee charged with the creation and
>>>> maintenance of open-source software related to persistence, storage,
>>>> and retrieval middleware for relational and NoSQL databases"
>> From reading the homepage of the project, I got the initial impression that (like
stated below) Gora is an ORM framework for column stores (such as Cassandra). When reading
on, this initial definition is extended, just like the formulation above, in a couple of ways:
>> a) it implies also relational databases are targetted;
>> b) it extends the scope to all NoSQL databases.
> I still don't see that definition being extended above. ORM is middleware, and it 
> is focused on relational (traditional) DBs. I've added in NoSQL stores to cover
> non-relational (column oriented ones) and Hadoop stores that we are also
> targeting.

In my view, ORM is middeware, but not all middleware is ORM. That's why I see it as an extension.
More precise, you do state it's not just middleware, but "persistence, storage and retrieval
middleware", but even that in my view is not a synonym for ORM.

Looking at this from another angle, even the term ORM is probably not that good: it implies
a mapping between an object model (check, that applies) to a relational model (nope, that
does not apply for most NoSQL stores, they're definitely not relational).

>> The background of the project does state that it has "limited support for SQL databases"
and that it "ignores complex SQL mappings" so just out of interest, when would you use Gora
over for example JDO (or JPA or Hibernate) when using a SQL database?
> I think this might be a good thread over on gora-dev if you are interested. We'd be happy
> to answer it there.

Good point, just did that.

>> The discussion you might get into with b) is that NoSQL is a very broad term and
the actual NoSQL implementations vary wildly. You do state you support column stores, key-value
stores and flat files, so probably summarizing that as NoSQL is reasonable.
> Cool, yeah that's what I thought.
>> A further question I have is that Gora has a "specific focus on Hadoop", the "main
use case for Gora is to access/analyze big data using Hadoop" which seems to indicate at least
some kind of relation to Hadoop and I would think that would be worth mentioning in the formulation
> I debated doing that too, Marcel. How would you update the sentence above to include
> Please suggest one and we'll try and integrate.

My question is, does Gora require Hadoop, or is it just that its main use case just happens
to involve Hadoop for splitting up the large amounts of data?

>>>> Also the STATUS page says that Gora is an ORM for column-stores. So,
>>>> one would ask why has that expanded here.
>>> ORM for column-stores is largely equivalent to persistence, storage, and 
>>> retrieval middleware since ORM just expands to "object relational mapping", 
>>> which is responsible for persistence, storage and retrieval. ORM to me is
>>> more nebulous, so I formulated and expanded description. 
>> From my brief analysis above, I'd say the definition on the status page might be
a bit too narrow (assuming the statements on the homepage do a better job of explaining Gora,
I have not actually used it). My question about its relation to Hadoop remains.
> Thanks, yeah like I said if you've got a better idea at a sentence to use in the board
> resolution, I'm all ears.

What about:

"open-source software for mapping objects to NoSQL databases"

and, IF it somehow requires Hadoop (see question above) that definition should probably be
extended with something like "for Hadoop".

Greetings, Marcel

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message