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

[Emmanuel Bernard]

In the forum came an interesting proposal for Hibernate OGM.
https://forum.hibernate.org/viewtopic.php?f=31&t=1037739&sid=9ee9d4772ac6dfaa67a37ec02b2c330c&p=2482498#p2482498

Today I think OGM works quite well for document store and even Neo4J because they don’t have any schema and thus we can store the data in a natural fashion.

For k/v stores, it is so flexible that OGM imposes its tuple structure to represent the object. This is good enough but has a few drawbacks:

- to read the data back you need the OGM classes around or at least how they are structured
- being detyped, they tend to be hard to query by the k/v query capability
- we store more data than we could as we copy the column names in each entry

Some k/v stores do have the notion of “schema”. Infinispan uses Protobuf and ask the user t provide the proto schema. Coherence and Hazelcast uses the Portable Object Format (invented by the coherence guys AFAIK). Hibernate OGM makes no use of these. We could use these schema to express the Tuple (which is essentially a Map) but that’s not what people are looking for I think.

What people are looking for is a way to defined a set of schemas (protobuf or POF) corresponding to the entities and have OGM use the schema to store a given serialized entity. This solves the problems above, in particular the capability to use the native query options of the k/v store and the compactness.

I can see that being conceptually possible as long as we ignore associations. The schema would describe the properties, even the embeddable and collection of embeddable objects. As long as these “schema” library let us write the data in a untyped fashion, something akin to:

    entityStructure = schemaLib.as(schemaId);
    entityStructure.putProperty(“firstname”, tuple.get(“firstname”) );
    addressStructure = entityStructure.addNestedObject(“address”);
    addressStructure.addProperty(“city”, tuple.get(“address.city”) );
    

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.

Thoughts?

Emmanuel