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

[Gunnar Morling]

To me the user's problem appears to be that the POF approach mixes a data
type and its (de-)serialization logic within one class. Specifically, you
need to implement a Hazelcast interface to do so:

    public class MyEntity implements Portable {

        Long id;
        String name;

        ...

        @Override public void writePortable( PortableWriter writer ) throws
IOException { ... }
        @Override public void readPortable( PortableReader reader ) throws
IOException { ... }
    }

In my understanding that's where the request for passing the entity object
to the dialect as is comes from; without the actual entity available, you
can't get hold of the (de-)serialization routine needed to put the stuff
into the datastore and get it back.

IMO that'd not be the right approach, though. a) Implementing
store-specific interfaces in entities seems against the whole nature of OGM
(esp. when taking polyglot persistence into the picture), b) it circumvents
things such as @Column names, type conversion (which may be needed to
convert property types allowed by JPA but not naturally supported by the
store) etc.

So instead of letting the entity types implement Portable, the dialect
should deal with this. Question is how it can be done in a generic fashion
with the given APIs. Yes, there could be a single Portable implementation
employed by the dialect which can serialize a given entity tuple. But upon
read-back that generic implementation wouldn't know which properties to
read from the persisted stream.

One approach would be to automatically generate the Portable
implementations, based on the entity types present. Either up-front via
some kind of build plug-in or dynamically at runtime (it may be challenging
to ensure constant "class ids" required by portables). This approach could
be implemented with OGM as is, it only puts the burdens of schema
management etc. entirely to the dialect.

But I'd start like that, see how it flies and then examine how more logic
could be moved onto the OGM core side.

--Gunnar



2015-01-13 22:03 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> 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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>