Hi Lukas,
I didn't do the alias impl. It was the original reason why
I wanted the columns to be instances. But the aliasing was used only once
so put it in the backburner.
Suggestions in the code generation part would be
- The variable declarations had full class names (with package). That
made it hard to read.
- We generate all the table references in a single interface. Makes it
easier to import.
thanks and regards,
-kps-
On Tue, Nov 15, 2011 at 12:42 PM, Lukas Eder <[email protected]> wrote:
> 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
> >
>
