Hello, Thanks for the feedback!
> I don't remember of changing anything in jooq for it (would have to > check it out). It looks as though the org.jooq.impl.TableImpl implementation had to be slightly changed, in order to "mix in" functionality from org.jooq.impl.TableAlias: https://github.com/lukaseder/jOOQ/commit/c7c46609c6d32577a415a3f2b02b9b54b46ea76b#diff-52 But maybe you found a different solution... The nice thing is that jOOQ 2.0 mostly stays backwards-compatible with 1.x Cheers Lukas 2011/11/15 kps <[email protected]>: > Hi Lukas, > > The second option is what we had done and works well. > > "and one or two jOOQ internals" > > I don't remember of changing anything in jooq for it (would have to > check it out). > > > regards, > -kps- > > > > > On Nov 15, 1:03 am, Lukas Eder <[email protected]> wrote: >> Hello community >> >> I have now evaluated two options of decreasing verbosity with aliasing: >> >> 1. Replace classes by interfaces. Tables stay static members, fields >> are methods in tables:https://sourceforge.net/apps/trac/jooq/ticket/688 >> >> 2. Replace static members by instance members and let generated tables >> return copies of themselves from the as() >> method:https://sourceforge.net/apps/trac/jooq/ticket/117 >> >> Option 1 has the advantage that it is easier to use polymorphism for >> custom extensions as suggested by Sander, even remote ones like >> Postgres' (multiple!) table inheritance. The disadvantage is that >> fields would always be followed by parentheses(), and besides, this >> would be a major change in jOOQ's internal architecture, with risk of >> major bugs. >> >> Option 2 has the advantage that it is easy to implement in jOOQ and >> does not touch jOOQ architecture. Only the code generator needs to be >> slightly adapted, and one or two jOOQ internals. I currently don't see >> any disadvantage at all. Besides, this has proven to work well for >> QueryDSL, a similar framework as jOOQ, with more focus on general >> querying rather than full-fledged SQL. See the discussion with Timo >> Westkämper here:https://groups.google.com/forum/#!topic/jooq-user/VNyevvq6MmY >> >> In order to reduce the implementation risk and the impact on the API, >> I have chosen option 2 and will not implement #688. The choice whether >> to generate static or instance members is up to the user. This will be >> a jooq-codegen parameter, which defaults to "instance members". Even >> when upgrading to jOOQ 2.0, you can continue using the static model. >> >> A complex sample query involving quite a bit of aliasing and >> subquerying can be found in my most recent blog >> post:http://lukaseder.wordpress.com/2011/11/14/jooq-meta-a-hard-core-sql-p... >> >> Beta testers are very welcome! Download the latest snapshot >> here:https://oss.sonatype.org/content/repositories/snapshots/org/jooq/ >> >> Cheers >> Lukas >
