Offer flexibility in the k/v key representations

Description

Today the key used is a PersistentEntityKey class (and its association and idsource equivalent).

We could offer a few options to the user:

Options

Map keys as (Linked) Maps

Instead of a specific type, one could return a Map<String,Object> to represent the key. Which might be simpler to use outside of Hibernate OGM.
Note that for k/v that support externalizers, the persisted structure does not have to change necessarily.

Direct id for keys in single column cases

When the id is made of a single column and of a basic type, we can use that id as the key directly without having to create a PersistenceEntityKey structure.
It makes for a more natural access than the ad-hoc OGM structure (or even a map).

Note that for PersistentAssociationKey it would not work as this key structure is almost always complex (multiple columns like fk + index etc).

A discussion on key migration

Storing the column names as part of the key can help during "schema" modifications but only in subset of them.
A migration happens in batch or on the fly and relies ont he ability to lookup with the new id and if that fails, lookup with the old id and do a migration before putting it back.

There are several scenarios:

  • a new column is added (with a default value) or a column is removed: in this case, storing the column name does not help and a conversion / migration logic can be devised.

  • reordering of columns. if two columns of the same type are reordered, then you need column names to differentiate the two between the old and new structure and to guarantee your equality comparison.

  • when a type changes in one of the column, then you do not need the column name, the type will help during the equality comparison

  • when the data in the id column change but neither its type nor its structure: then some id value conversion logic needs to be devised but the column name cannot help (say an id was the ssn 123456789 and is now the country-ssn FR-123456789).

  • when the id value changes structure (same type) and the column name changes, then part of the logic in the previous point is optional and the column name can help.

Questions

There is an agreement that using PersistentEntityKey by default is preferred over the Map structure.

The remaining question is whether it is worth it to store the simple ids directly or via PersistentEntityKey. As the single benefit for migration is the case when the id value changes and the column name is changed (last point).

References

The discussion happened in the following thread http://lists.jboss.org/pipermail/hibernate-dev/2014-November/011929.html and on IRC / Hangout

Environment

None

Assignee

Unassigned

Reporter

Emmanuel Bernard

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Priority

Major
Configure