Mailing-List: contact dev-help@metamodel.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@metamodel.incubator.apache.org
Date: Wed, 14 Aug 2013 17:09:48 +0000 (UTC)
From: "Ian Varley (JIRA)" <jira@apache.org>
To: dev@metamodel.incubator.apache.org
Message-ID: <JIRA.12662798.1376032875552.65622.1376500188163@arcas>
In-Reply-To: <JIRA.12662798.1376032875552@arcas>
References: <JIRA.12662798.1376032875552@arcas>
Subject: [jira] [Commented] (METAMODEL-13) HBase support for MetaModel
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/METAMODEL-13?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
739888#comment-13739888 ]=20

Ian Varley commented on METAMODEL-13:
-------------------------------------

Valid points, especially in terms of not wanting the HBase metamodel adapto=
r to *require* everything that comes with Phoenix (system table, coprocesso=
r installation, specific byte encodings, etc). Metamodel needs to work with=
 raw HBase in the simplest way possible.

That said, for other standard SQL databases (like MySQL, Oracle, etc.), Met=
amodel does take advantage of the query parser, query model, system tables,=
 built in aggregations, etc., right? The existence of Phoenix puts HBase in=
 a class where it could be treated more like these than like a raw row stor=
e. It can still conform to the universal set of functionality, but in a way=
 that's more like MySQL than it is like raw HBase.

So perhaps a better approach is to think of adding an *additional* module -=
 there's the HBase module that goes against raw HBase (what you've already =
built), and then in the future maybe there's also an "HBase/Phoenix" module=
 that goes against HBase with Phoenix in between. The latter doesn't preclu=
de the former. (My guess is that the benefits of using the Phoenix version-=
-secondary indexes, parallelization, mutability, schema management, high-pe=
rformance aggregation--would eventually be compelling enough to make it a c=
ommon choice). If you agree, I'll file a JIRA for that. :)
               =20
> HBase support for MetaModel
> ---------------------------
>
>                 Key: METAMODEL-13
>                 URL: https://issues.apache.org/jira/browse/METAMODEL-13
>             Project: Metamodel
>          Issue Type: New Feature
>            Reporter: Kasper S=C3=B8rensen
>            Assignee: Sameer Arora
>
> We have a separate remote Git branch for this ticket: 'hbase-module'.
> Refer also to the original eobjects.org ticket: http://eobjects.org/trac/=
ticket/1120

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira