From general-return-32912-apmail-incubator-general-archive=incubator.apache.org@incubator.apache.org Sun Dec 18 19:14:02 2011 Return-Path: X-Original-To: apmail-incubator-general-archive@www.apache.org Delivered-To: apmail-incubator-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B07479BE4 for ; Sun, 18 Dec 2011 19:14:02 +0000 (UTC) Received: (qmail 88125 invoked by uid 500); 18 Dec 2011 19:14:02 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 88001 invoked by uid 500); 18 Dec 2011 19:14:01 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 87986 invoked by uid 99); 18 Dec 2011 19:14:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Dec 2011 19:14:01 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [128.149.139.105] (HELO mail.jpl.nasa.gov) (128.149.139.105) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Dec 2011 19:13:54 +0000 Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBIJDUxs003193 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Sun, 18 Dec 2011 11:13:31 -0800 Received: from ALTPHYEMBEVSP20.RES.AD.JPL ([128.149.137.83]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Sun, 18 Dec 2011 11:13:30 -0800 From: "Mattmann, Chris A (388J)" To: "general@incubator.apache.org" CC: "gora-dev@incubator.apache.org" Date: Sun, 18 Dec 2011 11:15:28 -0800 Subject: Re: [VOTE] Gora Graduation Resolution Thread-Topic: [VOTE] Gora Graduation Resolution Thread-Index: Acy9uSA7RpJFsl8NRYCchhTSwIjMfA== Message-ID: References: <33CCA8D3-243C-4140-8CA2-5BEB2604EADC@jpl.nasa.gov> <4A16954D-B0AC-4F4E-8277-48A4DCA9512B@luminis.nl> <0443BF3C-BBFC-4782-B73F-E78718B4B6FE@jpl.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: chris.a.mattmann@jpl.nasa.gov X-AUTH: Authorized X-Virus-Checked: Checked by ClamAV on apache.org Hey Marcel, On Dec 18, 2011, at 10:14 AM, Marcel Offermans wrote: >=20 > 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 middlewar= e, but "persistence, storage and retrieval middleware", but even that in my= view is not a synonym for ORM. >=20 > Looking at this from another angle, even the term ORM is probably not tha= t 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, the= y're definitely not relational). Meh, to each their own :-) In general, I agree that ORM implies relational,= but Gora is *like* an ORM: it uses schema (specified using AVRO JSON) to identify objects to store, to retriev= e, and to query for, obfuscating the underlying data store. To me, this is precisely what ORMs like e.g., Hibern= ate, Derby, etc., do, and I think=20 that's the same idea that Enis and others who started the project had in mi= nd. Right now we support a combination=20 of Hadoop databases (HBase), and column oriented stores (Cassandra) and als= o relational (SQL) stores. >>=20 >> I debated doing that too, Marcel. How would you update the sentence abov= e to include Hadoop? >> Please suggest one and we'll try and integrate. >=20 > 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? It doesn't require Hadoop -- you can use Gora with SQL too -- but I think o= ur focus is on NoSQL. The major difference is that you=20 specify your schema in AVRO (which I think Gora is the only ORM type techno= logy I've seen that uses AVRO for that) compared=20 to some other Domain Specific Language (e.g., IDL, some new XML language, w= hatever).=20 >=20 >=20 > What about: >=20 > "open-source software for mapping objects to NoSQL databases" I'm cool with that. I think others in the Gora community would be too. I'm CC'ing them now and if I don't hear objections, I'll update (pending the outcome of this VOTE on general@) the board resolution when I post to board@ with that text. Now that I've answered your concerns, hopefully I look forward to your=20 expressing your VOTE on this thread. Thanks Marcel. >=20 > and, IF it somehow requires Hadoop (see question above) that definition s= hould probably be extended with something like "for Hadoop". It doesn't require it, so maybe it's fine to leave out Hadoop. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattmann@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org