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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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.

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.

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.

Sanne On 20 Jan 2014 16:42, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: > Ah, is that specified somewhere? I couldn't find anything in the spec from > a quick look. > > > 2014/1/20 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > > > 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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On 21 January 2014 13:25, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2014/1/21 Sanne Grinovero <sanne(a)hibernate.org&gt; >> >> 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-insid... - 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(a)hibernate.org&gt; wrote: >>> >>> Ah, is that specified somewhere? I couldn't find anything in the spec >>> from >>> a quick look. >>> >>> >>> 2014/1/20 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >>> >>> > 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(a)lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >