intermediate step types

[tod...@googlemail.com]

Hi Lukas,
in your latest blog post you states regarding those Step types:
"You should never reference these types directly, nor see them in your own code. They are intermediate DSL artifacts"

I usually create my dynamic queries with those types, e.g.

SelectConditionStep<Record> statement = jooq.select(ATTEST.fields()).from(ATTEST).where(buildFilterCondition(filter));
...
SelectSeekStep1<Record, ?> orderStep = null;
if (sortOrders == null || sortOrders.size() == 0) {
    // default sort order: ID
    orderStep = statement.orderBy(ATTEST.ID);
} else {
    // specialized order
    ...
}
return orderStep.limit(limit)
            .offset(offset)
            .fetchInto(Attest.class);

In order to avoid those intermediate DSL artifacts, I try to use QueryParts and their derived classes like org.jooq.Select

But that didn't work, the copmpiler complains:

Select<Record> statement = jooq.select(ATTEST.fields()).from(ATTEST).where(buildFilterCondition(filter));
together with
var orderStep = statement.orderBy(ATTEST.ID);
leads to
The method orderBy(TableField<AttestRecord,Integer>) is undefined for the type Select<Record>

But changing the return type of Select<Record> statement into the specialized Select<AttestRecord>

leads to
Type mismatch: cannot convert from SelectConditionStep<Record> to Select<AttestRecord>

How can I solve this problem in order to prevent the usage of those interdemiate step types ?

Kind regards

Dominik

[Lukas Eder]

Hi Dominik,

On Tue, Sep 6, 2022 at 3:20 PM 'tod...@googlemail.com' via jOOQ User Group <jooq...@googlegroups.com> wrote:

Hi Lukas,
in your latest blog post you states regarding those Step types:
"You should never reference these types directly, nor see them in your own code. They are intermediate DSL artifacts"

For others wondering, this is the blog post:

https://blog.jooq.org/a-brief-overview-over-the-most-common-jooq-types/

 

I usually create my dynamic queries with those types, e.g.

SelectConditionStep<Record> statement = jooq.select(ATTEST.fields()).from(ATTEST).where(buildFilterCondition(filter));
...
SelectSeekStep1<Record, ?> orderStep = null;
if (sortOrders == null || sortOrders.size() == 0) {
    // default sort order: ID
    orderStep = statement.orderBy(ATTEST.ID);
} else {
    // specialized order
    ...
}
return orderStep.limit(limit)
            .offset(offset)
            .fetchInto(Attest.class);

In order to avoid those intermediate DSL artifacts, I try to use QueryParts and their derived classes like org.jooq.Select

But that didn't work, the copmpiler complains:

Select<Record> statement = jooq.select(ATTEST.fields()).from(ATTEST).where(buildFilterCondition(filter));
together with
var orderStep = statement.orderBy(ATTEST.ID);
leads to
The method orderBy(TableField<AttestRecord,Integer>) is undefined for the type Select<Record>

But changing the return type of Select<Record> statement into the specialized Select<AttestRecord>

leads to
Type mismatch: cannot convert from SelectConditionStep<Record> to Select<AttestRecord>

How can I solve this problem in order to prevent the usage of those interdemiate step types ?

.selectFrom(ATTEST)

.where(...)

.orderBy(isEmpty(sortOrders) ? List.of(ATTEST.ID) : /* specialized order */)

.fetch();

I mean, it's the exact same approach you already chose for where(). orderBy() is no different.

Note that starting with jOOQ 3.17, there's DSL.noField(), which creates a dummy field that is ignored by most clauses, avoiding the clause if there are no fields in it:

https://github.com/jOOQ/jOOQ/issues/2333

Hope this helps,
Lukas