Oh, another thing that is obviously a difference (but potentially in a good way) is the support for various datastores. I see that in Gora you have support for stores such as Cassandra and Solr, which isn't in MetaModel currently. But it would be a good reason to make such modules in MM. Right now MM offers connectivity to a lot of other backends though, such as CouchDB, MongoDB, a lot of different file-based datastores and of course JDBC databases. I think there's some overlap but certainly also some value in consolidating there.
2014-09-13 9:49 GMT+02:00 Kasper Sørensen <i.am.kasper.soren...@gmail.com>: > Hi Lewis and Henry, > > 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 ... :-) > > I can imagine that probably this means that your execution is quite > optimized for these few scenarios. 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. 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. 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. > > 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. 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. > > 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. > > Best regards, > Kasper > > 2014-09-13 7:57 GMT+02:00 Lewis John Mcgibbney <lewis.mcgibb...@gmail.com> > : > >> Hi Kasper >> >> On Fri, Sep 12, 2014 at 10:47 PM, <dev-digest-h...@gora.apache.org> >> wrote: >> >> > >> > Curious to hear what you think! >> > >> > I personally think that this is an excellent idea. >> I am aware that Henry has been monitoring you guys for a while now and we >> were actually talking a bit about MetaMode this week infact. >> I think that we could certainly explore integration of MetaModel into Gora >> as one of the defining feature drives within the 0.6-SNAPSHOT development >> drive. >> We are VERY close to releasing Apache Gora 0.5 (1 issue to addres) then we >> can begin work on this. >> I wonder if you've looked into the Gora Query API at all? If so, if you >> could comment on what aspects you think MetaModel would address. >> Please feel free to open a JIRA ticket on or Jira and we can make this >> happen. >> Thanks Kasper. >> Lewis >> > >
