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

[Sanne Grinovero]

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