Kevin,
I never give any advice using universal quantifiers, such as "always" or
"all" or "never", etc.
Cheers,
Lukas
On Fri, Sep 13, 2024 at 9:53 AM Kevin Jones
wrote:
> Bingo!!
>
> Thank you :)
>
> So should all those 'hard-coded' values use 'inline' ?
>
> Kevin
>
> On Fri, Sep 13, 2024 at 8:
Bingo!!
Thank you :)
So should all those 'hard-coded' values use 'inline' ?
Kevin
On Fri, Sep 13, 2024 at 8:37 AM Lukas Eder wrote:
> So, try replacing .eq(1) by .eq(inline(1)) on the original query
>
> On Fri, Sep 13, 2024 at 9:30 AM Kevin Jones
> wrote:
>
>> Thanks Lucas.
>>
>> so I've na
So, try replacing .eq(1) by .eq(inline(1)) on the original query
On Fri, Sep 13, 2024 at 9:30 AM Kevin Jones
wrote:
> Thanks Lucas.
>
> so I've narrowed this down.
>
> My original CTE looks like this:
>
> fun createTemporaryInnings(matchType: String, fieldingCteName: String):
> SelectHavingSte
Thanks Lucas.
so I've narrowed this down.
My original CTE looks like this:
fun createTemporaryInnings(matchType: String, fieldingCteName:
String): SelectHavingStep> {
val selInningsNumber = select(
field("matchId"),
field("teamId"),
field("opponentsId"),
field
Hi Kevin,
The main differences are:
- jOOQ uses bind values by default, not inline values. There might be edge
cases where this bothers optimisers
- jOOQ fetches all results in memory eagerly by default. JDBC (and JDBC
based UIs) are lazy, fetching only a few records
Other than that, I'd have to
I'm not sure if this is a stupid question.
I have an application that uses JOOQ. It's a desktop app written in Kotlin
using SQLite as the database with a lot of fairly complex queries. Within
the app one of the queries takes about 11 seconds to run. If I take the
generated SQL for that query and r
