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
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. At which stage, I could invoke
the What?! card. But it would make sense to expose that info for datastores like
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:
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
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.
hibernate-dev mailing list