gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <i.am.kasper.soren...@gmail.com>
Subject Re: Possible collaboration between Gora and MetaModel to deliver datastore concept?
Date Tue, 16 Sep 2014 05:54:14 GMT
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.sorensen@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.mcgibbney@gmail.com>
> :
>> Hi Kasper
>> On Fri, Sep 12, 2014 at 10:47 PM, <dev-digest-help@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message