On 19 Jun 2014, at 11:12, Gunnar Morling <gunnar(a)hibernate.org> wrote:
I'm looking into this atm.
My thinking is to pass a new dedicated Type IdGeneratorKey instead of RowKey to
GridDialect#nextVal() which can carry all the information we need. The dual use of RowKey
for association rows and sequences has been confusing anyways.
Yes that’s a good idea.
2014-06-06 10:44 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
I guess it is particularly questionable to have an identity generator be mapped to an
ad-hoc table based generator. Remember the angle we came from: make a JPA application work
when storing data in Infinispan. Unlike other datastores, Infinispan has not notion of id
generation whatsoever.
sequenceName should map to on of the OgmTableGenetator settings somehow.
+1
valueColumnName is something that I elected no to use because NoSQL we bind to so far do
not have a strong schema. And at at given segmentColumnValue only correspond a single
value. It would come and bite me if someone for the same segment value had two different
value column names to differentiate two different sequence.
Would it really bite you? I think e.g. MongoDB could perfectly handle this case via two
different fields for the two sequences in the same document/segment.
@TableGenerator(
name=“1”,
table=“Seq_table”,
pkColumnName=“key”,
pkColumnValue=“1”,
valueColumnName=“value1”
)
@TableGenerator(
name=“2”,
table=“Seq_table”,
pkColumnName=“key”,
pkColumnValue=“1”,
valueColumnName=“value2”
)
The two definitions share the same options except for valueColumnName.
The table is roughly as followed
TABLE(Seq_table)
key | value1 | value2
1 | 10 | 24
What would be the MongoDB representation in your approach?
But as this does not really seem like a best practice, we could also handle it as a
definition error if the same table is used with different value column names in different
generators. We could raise an error during bootstrap.
I am not a huge fan but I could live with that as long as it is detectable.