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