On 21 January 2014 13:25, Gunnar Morling <gun...@hibernate.org> wrote: > 2014/1/21 Sanne Grinovero <sa...@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" <gun...@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 <emman...@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@lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
