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

[Emmanuel Bernard]

What you are describing is what we want to do at some point but it is definitely a few steps further.
Usually, in the maturation cycle, we code things in the dialect and then we try to extract the logic out into core.

And since it’s a non trivial set of new features, I’d rather we go by reasonable steps:
1. dialect level POF/protobuf support
2. dialect level multi storage support
3. ability to express JPA mapping with a programmatic API (for multi mappings expression)
4. core level multi storage support
5. query level use of the multi storage support

Gunnar mentioned that at least for Hazelcast, you cannot necessarily pass the POF data directly to the grid, you might be in need of a 1-1 mapping between a POJO and a POF which is making the whole idea of step 1 more convoluted already if true.

Emmanuel

> On 13 Jan 2015, at 22:03, Sanne Grinovero <sanne at hibernate.org> 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 at hibernate.org> wrote:
>> 
>>> On 13 Jan 2015, at 18:06, Emmanuel Bernard <emmanuel at hibernate.org> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev