2014-06-19 13:34 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
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
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.
> 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
The two definitions share the same options except for valueColumnName.
The table is roughly as followed
key | value1 | value2
1 | 10 | 24
What would be the MongoDB representation in your approach?
It would look like this:
"_id" : 1,
"value1" : 10,
"value2" : 24
So you would get the different sequence values from different fields of
that same document. But I wouldn't recommend to do so due to the potential
contention on that single record. Thus I'd raise at least a warning during
bootstrap. As it's not portable to stores with a fixed schema, I'd rather
not support it at all, though, and raise an error.
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
I am not a huge fan but I could live with that as long as it is detectable.