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 <st...@hibernate.org> Hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
