Re: [hibernate-dev] [OGM] Id generation strategies
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
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?
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
bootstrap.
I am not a huge fan but I could live with that as long as it is detectable.