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

Sanne Grinovero sanne at hibernate.org
Tue Jan 21 08:51:58 EST 2014


On 21 January 2014 13:25, Gunnar Morling <gunnar at hibernate.org> wrote:
> 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?

Confused. I'm stating the opposite: if the user is explicitly
demanding IDENTITY strategy, we should not override that.
Otherwise he/she should definitely use AUTO.

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

Sure, you get an exception. You don't have to implement it from a spec
perspective, I'm just saying it's nice to have and makes a lot of
sense for practical needs to support Longs rather than UUIDs.

>>
>> 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?

Agree, and confused too. I didn't know we where actually using TABLE,
although in our "databases" the difference might be unclear in some
cases?

>>
>> 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?

- http://belaban.blogspot.co.uk/2013/08/how-to-hijack-jgroups-channel-inside.html
- https://raw.github.com/belaban/JGroups/master/doc/design/FORK.txt

The docs specifically make the COUNTER example, as that's what I had
in mind when we designed the new protocols ;-)
We created this _because of_ the OGM needs.

Sanne

>
>>
>> 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
>
>


More information about the hibernate-dev mailing list