Re: [hibernate-dev] [OGM] Store objects as actual typed objects via the native grid format

On 13 Jan 2015, at 22:03, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: Many interesting ideas. Is the culprit not simply to be able to store the same entry into multiple (different) representations? I'd like to see the separation into "different representations" not being handled at the level of the dialect but higher up at level of OGM/ORM core, so that one could have - for example - some entities stored into a relational database, some other entities into MongoDB, and some entities into *both*. So configuration wise I'd have a section for each dialect, and then a way to tag each entity - possibly multiple times - to have then included into one of the configured databases. You'd have two consequences: - you can have multiple instances of the same dialect type - for example two Coherence instances using a different POF encoding strategies - the Query engine can pick the best strategy among all storage options, across both differences of representation into the same database but also across query technologies / capabilities @Entity @PersistenceGroup(“mongo-cluster-of-foos”, "cassandra-times") public Foo { … } A limitation is that I'd probably want to be able to mark various additional mapping annotations as belonging to a specific database only. For example I think a relation annotation like @ManyToOne should be the same on all - as it's related to the structure of the Java domain model - but other annotations such as @Column would need to have a qualifier so I can pick multiple different ones. The obvious solution is that such mapping solutions need to be externalized into mapping files (exclusively). In practice this might not be a too strong limitation, in all places I've worked the "@Column" annotation was the quick and dirty solution but people would prefer to make a corporate standard NamingStrategy which would consolidate such decisions out of the model. However you decide on those, the Query execution would need the smart planner we've fantasized about a bit. Somehow related: remember Adrian Nistor from the Infinispan team developed a mapping tool based on annotations to map POJOs to Protobuf. This is ready for general usage now, and could be useful here. -- Sanne On 13 January 2015 at 17:24, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > >> On 13 Jan 2015, at 18:06, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >> Note that the user here (see question c), also asks for the ability to denormalize the data and store a full object graph as one key and only a subset as a second key which is something we want to do but that we don’t have right now. > > Actually, even that could be done by an ad-hoc dialect which would store the full entity graph in one schema / cache and the normal (according to OGM) entity in another schema/cache. The Dialect does not give you the entity graph but since we now know how to batch work, we could apply all changes on the virtual entry about to be persisted. This is essentially what we do in MongoDB’s dialect that we could replicate here. > > Also, the POF(s) / Protobuf(s) for a given entity could be defined via the option system at the entity level > > @Entity @UsingSchema(“someSchemaId”) > public Foo { … } > > How to chose one vs the other at query time (via OGM) is what we are the farthest from I suspect. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev