Guten Tag Lukas Eder,
am Freitag, 7. Februar 2020 um 17:04 schrieben Sie:
> It's a lot of code. If you could TL;DR-summarize it with 6-7 lines, I'll be
> happy to look at it.
Couldn't reduce less, so if it's still too much, nevermind, I'll deal
with it when executed and in case it breaks. I know
On Fri, Feb 7, 2020 at 4:50 PM Thorsten Schöning
wrote:
> Guten Tag Lukas Eder,
> am Freitag, 7. Februar 2020 um 15:37 schrieben Sie:
>
> > Does this make sense?
>
> Absolutely, thanks! :-) You only have my old code, already changed it
> to what you suggested right now. BUT: Not with using a
Guten Tag Lukas Eder,
am Freitag, 7. Februar 2020 um 15:37 schrieben Sie:
> Does this make sense?
Absolutely, thanks! :-) You only have my old code, already changed it
to what you suggested right now. BUT: Not with using a custom table,
but my former approach with individual, unrelated fields
On Fri, Feb 7, 2020 at 4:15 PM Thorsten Schöning
wrote:
> Guten Tag Thorsten Schöning,
> am Freitag, 31. Januar 2020 um 19:06 schrieben Sie:
>
> > I tried following the approach jOOQ is doing by simply creating
> > classes with fields for each CTE and their columns.[...]
>
> One can get exactly
Guten Tag Thorsten Schöning,
am Freitag, 31. Januar 2020 um 19:06 schrieben Sie:
> I tried following the approach jOOQ is doing by simply creating
> classes with fields for each CTE and their columns.[...]
One can get exactly what jOOQ does by using the code generator with a
schema for a
On Fri, Feb 7, 2020 at 3:23 PM Thorsten Schöning
wrote:
> > No, but it makes working with them easier, as they now behave like
> ordinary
> > tables / views.
>
> I still don't get it: There's no place where I can interchange CTEs
> and my custom tables, only reuse individual components.
In
Guten Tag Lukas Eder,
am Freitag, 7. Februar 2020 um 13:34 schrieben Sie:
> Sure. But since this is a public list, with a few folks lurking, I always
> like to open up discussions to broader topics[...]
And that's exactly how I understood your mail and why I brought my
opinion into this
On Fri, Feb 7, 2020 at 11:50 AM Thorsten Schöning
wrote:
> So in my opinion things break down to if anything from the code
> generator is used or not. If so, one wouldn't want to deal with plain
> strings anymore at any place and express everything using names,
> fields etc. from jOOQ instead I
Guten Tag Lukas Eder,
am Donnerstag, 6. Februar 2020 um 14:43 schrieben Sie:
> Do note that you can also work with string-based SQL and parse that using
> jOOQ's DSLContext::parser API:
> https://www.jooq.org/doc/latest/manual/sql-building/sql-parser/
If I understood things correctly, that
Hi Thorsten,
Thanks for describing your very interesting use case.
In theory the CTE itself is the same like a table jOOQ would generate
> columns for, so I as well really created one field per column per CTE.
Absolutely! Eventually, we're hoping to be able to offer more powerful APIs
to
Guten Tag Thorsten Schöning,
am Freitag, 31. Januar 2020 um 13:15 schrieben Sie:
> CTEs are query-level and therefore not part of the classes jOOQ
> generates based on some schema for Java, that's why I wonder how to
> best handle names of CTEs themself, the columns they produce etc.
I tried
11 matches
Mail list logo
