Hi again guys,
So to get this started I would like to try and hack away on some (probably
disposable) attempt of an integration. My initial question is already:
Should I start a new module ("gora-metamodel") or try and refactor an
existing module (e.g. "gora-sql" or so) to use MetaModel under the covers.
I guess doing either of those would be a nice first experiment.
Kasper
2014-09-16 18:02 GMT+02:00 Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>:
> Hi Kasper,
>
> On Mon, Sep 15, 2014 at 9:06 AM, <dev-digest-h...@gora.apache.org> wrote:
>
> >
> > Glad to see that this interests you. I did look quickly into the Gora
> Query
> > API (just the javadocs for now) and got the impression that your query
> > model is mostly focused around a few specific types of queries; such as
> > "get a record by it's key", "get a range of records by a key-range", "get
> > records by it's timestamp". I am still no expert, so excuse me if I make
> > the wrong conclusions here ... :-)
> >
>
> Nope, you're more or less absolutely right. This reflects the same way we
> load data into Gora.
> It is however also important for me to clarify that we also support
> void *setFields
> <
> https://builds.apache.org/view/All/job/gora-trunk/javadoc/org/apache/gora/query/Query.html#setFields%28java.lang.String...%29
> >*
> (String
> <
> http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true
> >
> ... fieldNames) void *setFilter
> <
> https://builds.apache.org/view/All/job/gora-trunk/javadoc/org/apache/gora/query/Query.html#setFilter%28org.apache.gora.filter.Filter%29
> >*
> (Filter
> <
> https://builds.apache.org/view/All/job/gora-trunk/javadoc/org/apache/gora/filter/Filter.html
> >
> <K
> <
> https://builds.apache.org/view/All/job/gora-trunk/javadoc/org/apache/gora/query/Query.html
> >
> ,T
> <
> https://builds.apache.org/view/All/job/gora-trunk/javadoc/org/apache/gora/query/Query.html
> >
> > filter) This above operands are self explanatory. Filters are implemented
> on a datastore-by-datastore basis however and not all stores implement
> filters currently.
>
>
> >
> > I can imagine that probably this means that your execution is quite
> > optimized for these few scenarios.
>
>
> Somewhat. gora-hbase would ne an example of this being the case.
>
>
> > If we initially compare then performance
> > of MM and Gora's queries, it might be that Gora's queries run faster for
> > these specific scenarios.
>
>
> Possibly. This would be a useful test.
>
>
> > In MetaModel the approach to developing
> > datastores and query model was kinda the other way around: A very wide
> > range of query patterns is supported (the majority of SQL, for any
> > datastore), but it sometimes comes at a cost of performance, since
> > optimizing for certain scenarios is an optional implementation detail.
>
>
> For me, this is where there is value added.
>
>
> > But
> > should we go in and serve Gora with a query API, I of course believe that
> > we should make sure that we cover your typical query scenarios with
> optimal
> > execution strategies so that this isn't a problem.
> >
>
> +1
>
>
> >
> > The other big thing I notice is that your Query and Result classes have
> > some generics involved - as far as I can gather this is to serve domain
> > objects back into the result. So that I can have something like a
> > Query<Customer> or whatever it is that I am querying.
>
>
> +1
>
>
> > In MM we only care
> > about schemas, tables and columns with data. So all results (DataSet in
> MM)
> > contain rows of data. As such I can then see Gora acting as a mapping
> layer
> > between a MetaModel Row and a Gora Persistent object.
> >
>
> +1. This is where thd stength of Gora comes into it's own. This is exactly
> what I have personally stuck by the technology.
>
>
> >
> > A final remark on the Datastore level - in MetaModel we deliver a Schema
> > (contains Tables (contains Columns)) for each datastore. Sometimes the
> > schema is provided natively by some metadata API or something like that.
> In
> > other cases it is inferred by looking at the data contained in the
> > datastore. I couldn't find something quite like this in Gora.
> >
> >
> This is because there exists no such mechanism for that. We currently
> define a data model in JSON which is compiled into Java.
> We then provide a backend-specific XML mapping file which would map
> specific object fields to the pysical backend storage structure. The XML
> mapping can also define primary Key's by which we wish to repference the
> object, TTL's, compaction strategies, TombStone implementations, etc, etc.
> AN example would be as follows
> Consider an Employee -
>
> https://github.com/apache/gora/blob/master/gora-core/src/examples/avro/employee.json
> Cassandra Mapping -
>
> https://github.com/apache/gora/blob/master/gora-cassandra/src/test/conf/gora-cassandra-mapping.xml
> HBase Mapping -
>
> https://github.com/apache/gora/blob/master/gora-hbase/src/test/conf/gora-hbase-mapping.xml
> SOlr -
>
> https://github.com/apache/gora/blob/master/gora-solr/src/test/conf/gora-solr-mapping.xml
> etc
> Thanks
> Lewis
>
