2014-04-16 17:49 GMT+02:00 Garret Wilson <[email protected]>: > 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. >
We generally always recommend to use the code generator. You'll get 100s of features that you don't have without it. It's not too late. You won't regret it, I promise. The main reason for those many tableByName() methods and similar is that some users may simply not know the schema beforehand. Cheers Lukas -- 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.
