[hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM

[Gunnar Morling]

2014/1/21 Sanne Grinovero <sanne at hibernate.org>

> I don't know if that's explicitly defined in the spec, but even if it
> wasn't I wouldn't be happy as a user to see an exception for such a
> commonly used feature.
>
So you prefer to silently use another strategy than the one configured
instead of reporting the issue? Wouldn't rather a user work with AUTO if
she wanted the engine to choose a strategy?

Do you know how ORM handles the case of using IDENTITY on stores which
don't support it?

>  Clearly when such an ID is requested we need to invoke the server out of
> the batching / transaction context, which might be a suboptimal strategy
> but exactly what the user is asking for:theyr choice of they want to
> tradeoff simplicity for performance.
>
I'm not quite following. Using TABLE behavior instead of IDENTITY doesn't
seem like doing what the user has asked for?

>  Also to keep in mind for the Infinispan case the current approach is
> very slow but now that we've upgraded to latest wildfly there's a new
> feature could use to optimise for this: COUNTER protocol in JGroups
> combined with FORK channels.
>
That's interesting, do you have a pointer with more information on that?


>  Sanne
> On 20 Jan 2014 16:42, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>
>> Ah, is that specified somewhere? I couldn't find anything in the spec from
>> a quick look.
>>
>>
>> 2014/1/20 Emmanuel Bernard <emmanuel at hibernate.org>
>>
>> > The problem is that in JPA, IDENTITY returns a long, not a UUID.
>> >
>> > On Mon 2014-01-20 12:23, Gunnar Morling wrote:
>> > > Hi,
>> > >
>> > > While reviewing the PR for batch operations in OGM [1], I took some
>> time
>> > to
>> > > better understand OGM's approaches for id generation.
>> > >
>> > > Now I'm wondering about how GenerationType.IDENTITY is implemented.
>> The
>> > > corresponding generator (OgmIdentityGenerator) just delegates to a
>> > > table-based strategy, so an id is always pre-allocated and then passed
>> > into
>> > > the dialect when creating a tuple.
>> > >
>> > > I think it would be nice to have proper support for server-generated
>> ids,
>> > > in particular since some stores return the inserted id directly from
>> the
>> > > insert operation, i.e. without requiring another read.
>> > >
>> > > For the time being, as the current implementation doesn't really
>> adhere
>> > to
>> > > the semantics of GenerationType.IDENTITY, should we raise an error
>> when
>> > > using it instead of silently using another strategy?
>> > >
>> > > Thoughts?
>> > >
>> > > --Gunnar
>> > >
>> > > [1] https://hibernate.atlassian.net/browse/OGM-175
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>