Hi Kasper,
I think it would be better to have the gora-metamodel as metamodel supports
other input formats than just sql. This would be great!
Renato M.
2014-09-22 19:06 GMT+02:00 Kasper Sørensen <i.am.kasper.soren...@gmail.com>:
> 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
> >
>
