On Wednesday, April 16, 2014 12:42:54 PM UTC-3, Lukas Eder wrote: > > ... > Note, if you were using the code generator, then much of this information > would really be available on your tables - e.g. the identity column, in > this case. >
Yes, I want to use the code generator. But for this (aggressive) iteration of our product I wanted to as quickly as possible show that it was viable to use jOOQ. I figured I could get the same functionality and save lots of time by not figuring out how to set up classpaths and build scripts and integrate the generator into Maven, etc. I just wanted a quick-and-straightforward way I could test and prove jOOQ, and then if it worked I could come back in the next iteration and set up code generation going forward. I'll have to admit the results were mixed: not only was a major, useful feature broken (RETURNING), the workaround (curval()) wasn't implemented without doing yet *another* workaround (SequenceImpl). In hindsight maybe it would have been quicker to learn how to generate the classes. But that is only because of jOOQ limitations---how was I supposed to know the features *I* needed didn't work without class generation? Anyway, that's the story. Back to coding. Thanks again for the help. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
