2014/1/21 Sanne Grinovero <sa...@hibernate.org> > 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. >
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" <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
