Re: [hibernate-dev] [OGM] Id generation strategies
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.
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 bit you? I think e.g. MongoDB could perfectly handle this
case via two different fields for the two sequences in the same
document/segment.
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.
At which stage, I could invoke the What?! card. But it would make
sense to
expose that info for datastores like Cassandra.
I am fine if we put the whole subject back on the table and revisit. This
code has been written back when I was trying to prove that a brick could
not fly.
On 04 Jun 2014, at 15:36, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> Hi,
>
> I'm rather confused by the way how OgmIdentityGenerator,
> OgmSequenceGenerator and OgmTableGenerator interact.
>
> Basically, the first two just delegate to the latter. Now intuitively I'd
> have expected an exception when explicitly using a generation type not
> supported on a given datastore, say @GeneratedValue(strategy =
> GenerationType.SEQUENCE) on MongoDB. But as we always delegate to the
table
> strategy, such exception is not raised.
>
> Also several attributes of generator annotations are ignored; E.g.
> naturally(a)SequenceGenerator.sequenceName(), but also
> @TableGenerator.valueColumnName.
>
> What has been the motivation behind this design?
>
> I guess a change to GridDialect may be required for making explicit which
> strategies are supported on a given backend.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev