Hi, for some particular project, I'd like to have a custom IdentifierGenerator, which could be thought of as an extension of the "native" IdentifierGenerator. Basically, it ought to take the id generated by the "native" generator, but then do some magic with it, for example add a prefix. (Yes, I know, don't push me on that, I have already lost my struggle against a "telling ID".) Such an IdGenerator is easily implemented: Create a class, which queries the IdentifierGeneratorFactory for the "native" IdentifierGenerator and use that. (Works fine.) The problem is, that the "native" generator is sometimes implementing PostInsertIdentifierGenerator. Of course, I can have my generator implement PostInsertIdentifierGenerator as well, but that means that it will break on systems without a sequence. OTOH, I can remove the interface, but then it won't work on the other systems. An alternative might be, to add a new "myNative" term to the IdentifierGeneratorFactory, but that class neither allows extension (it's final, for whatever reason) nor does it support extending the map of builtin types. Any ideas? Thanks, Jochen

Hello, Steve, yes the answer for "why native?" is portability, indeed. Could you please enlighten me, what the "enhanced" generators precisely are and why they would fix my problem? At least, I don't find the term "enhanced" in the IdentifierGeneratorFactory and neither of the classes implementing IdentiferGenerator in the hibernate sources contain it. Thanks, Jochen On Fri, Dec 4, 2009 at 4:30 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > First I have to ask 'why native?'. Doing this with the native generator > will present you with an interesting challenge of how you handle > IDENTITY or other post-insert style generation. post-insert means after > the insert has happened, so how would you be adding your prefix? And > even if you answer that, generally speaking columns defined as IDENTITY > are not eligible for update. > > If the answer to 'why native?' is portability, then why not use the > "enhanced" generators. These are intended for portability in a much > better way then native was. > > On Fri, 2009-12-04 at 08:50 +0100, Jochen Wiedmann wrote: >> Hi, >> >> for some particular project, I'd like to have a custom >> IdentifierGenerator, which could be thought of as an extension of the >> "native" IdentifierGenerator. Basically, it ought to take the id >> generated by the "native" generator, but then do some magic with it, >> for example add a prefix. (Yes, I know, don't push me on that, I have >> already lost my struggle against a "telling ID".) >> >> Such an IdGenerator is easily implemented: Create a class, which >> queries the IdentifierGeneratorFactory for the "native" >> IdentifierGenerator and use that. (Works fine.) >> >> The problem is, that the "native" generator is sometimes implementing >> PostInsertIdentifierGenerator. Of course, I can have my generator >> implement PostInsertIdentifierGenerator as well, but that means that >> it will break on systems without a sequence. OTOH, I can remove the >> interface, but then it won't work on the other systems. >> >> An alternative might be, to add a new "myNative" term to the >> IdentifierGeneratorFactory, but that class neither allows extension >> (it's final, for whatever reason) nor does it support extending the >> map of builtin types. >> >> Any ideas? >> >> Thanks, >> >> Jochen >> >> > -- > Steve Ebersole <steve(a)hibernate.org&gt; > Hibernate.org > >