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 above. > > I debated doing that too, Marcel. How would you update the sentence above to > include Hadoop? > 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
