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

[Gunnar Morling]

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

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

Ok, then we're on the same page. But overriding is what actually happens
today, since OgmIdentityGenerator just delegates to OgmTableGenerator.


> Otherwise he/she should definitely use AUTO.
>

Right.


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

What I mean is, MongoDB and CouchDB can assign an id themselves when
inserting a record without passing in an id. This id is a UUID for these
stores. I think it would make sense to leverage that functionality on these
stores if IDENTITY is configured. Otherwise (a store doesn't provide such
functionality) an exception should be raised.


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

Agreed, the difference may be blurry, but I think mapping the IDENTITY
strategy to a store's capability to create ids "inline" when inserting a
document is feasible and would help avoiding some round trips to the store.


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

I see. Would be nice if you could file a JIRA issue with some more details
if you find some time, so the idea gets a bit more clear.


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