I searched hi and lo for a "*field*" method to add that projection, but
baseQuery.addSelect(...); is exactly what I was looking for. Thanks a lot Lukas, you are doing an awesome job with jOOQ! On Tuesday, May 15, 2018 at 9:20:45 AM UTC+2, Lukas Eder wrote: > > > > 2018-05-14 20:08 GMT+02:00 Simon Niederberger <[email protected] > <javascript:>>: > >> I'm assuming that by this, you mean using your query as a derived table. >>> Then, yes, you're not allowed to have ambiguous column names. Only top >>> level SELECT statements may expose ambiguous column names in SQL. >>> >>> However, I'm not 100% certain what you're trying to do. Would you mind >>> explaining your use case a bit more? >>> >> >> I need a Select implementation to which I can later add conditions and >> joins (not fluently, more like the Criteria builder of Hibernate), I came >> across SelectQuery which fits perfectly. To create such a SelectQuery, I >> find >> >> final SelectQuery<CustomfieldRecord> baseQuery = jooq.selectQuery( >> getTable()) >> whereas >> jooq.select(getTable().fields()).from(getTable()); >> returns a SelectJoinStep (for fluent queries). Adding a join later >> baseQuery.addJoin(BillingAccount.BILLING_ACCOUNT, Customfield.CUSTOMFIELD >> .ACCOUNT_UUID.eq(BillingAccount.BILLING_ACCOUNT.UUID)); >> baseQuery.addConditions(BillingAccount.BILLING_ACCOUNT.COMMUNITY.eq( >> principal.getCommunity())); >> results in selecting fields of both tables, as the internal projection is >> on '*'. >> > > Indeed, without any explicit projection, jOOQ is going to project "*" (or > rather, the explicit column list produced by all the tables, if it is > available from the meta model). You can easily add the projection yourself, > though: > > baseQuery.addSelect(...); > > > The confusing bit here is that you're getting a > SelectQuery<CustomfieldRecord>, whose type is misleading. This is a very > early API design flaw from version 1.0, which we haven't fixed for > backwards compatibility reasons. A workaround would be to use: > > SelectQuery<Record> baseQuery = jooq.selectQuery(); > baseQuery.addFrom(getTable()); > > > I wonder if we should deprecate that other method or improve its Javadoc... > > Adding >> baseQuery.fields(getTable().fields()); >> doesn't have the desired effect. >> > > Yes indeed. That method is for retreiving projected fields from the query, > not setting them: > > https://www.jooq.org/javadoc/latest/org/jooq/TableLike.html#fields-org.jooq.Field...- > > I suggest looking at these two pages for some ideas about what can be done > when doing dynamic SQL with jOOQ: > > - https://www.jooq.org/doc/3.10/manual/sql-building/dynamic-sql > - > https://blog.jooq.org/2017/01/16/a-functional-programming-approach-to-dynamic-sql-with-jooq > > A mistake a lot of people make is they want to use either the DSL API or > the model API as a model for their intermediate "partial" or "incomplete" > queries. That's often not a good idea. Granted, the APIs could be improved > to allow for that, but they haven't been designed this way. > > I hope this helps, > 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.
