On 26 Nov 2014, at 12:42, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
ORDERED_ARRAY_STRATEGY could be an Enum, and give you some flexibility
among your proposals. With the current model I'd stick to the Map as
they are the only one safe enough,
I don’t know what you mean by ordered array strategy and enum.
The rest of the sentence seems to imply that you prefer option 3 even for the single id
column case. Correct?
You make a great point about making it easier to run native queries.
Is that a new goal we have? It seems we have to define the goals we
want, as the proper data abstraction goal seems to clash with it.
I'd rather make a custom Query walker which understand how we store
things in Infinispan, and keep the safety of our more verbose and less
efficient storage model. For example an inspection tool connected to
the grid could choose to not show the "SchemaId" tokens, but use them
to be able to render the entry in some human understandable way, like
by adding the column names on a table.
These are not really new goals.
Goal #1: make the most natural mapping as possible as if you were not using the ORM but
rather use the tool directly.
Goal #2: expose the native query capabilities as a first class citizen and on equal
footing as the JP-QL support to benefit from the specificities of your NoSQL backend.
Non Goal: Hibernate OGM is not in the database business - at least until we explore the
polyglot persistence topic :)
Now Goal #1 is a bit blurred by the fact that you could consider the use of a data grid as
a secondary and mostly temporary store of a data set persisted elsewhere. I which case
the JPA API prevails as the entry point and how you store the data in the grid is not
important. But that’s one use case.
We didn't mention javax.persistence.IdClass but I assume the same
applies.
Yes, IdClass with a specific type are like embeddable ids essentially. And implicit
IdClass (forgot what they are called) means that the entity class itself is also the id
class.