Hi Thorsten,
Thank you very much for your message.
The main reason for these types is to provide type safety *within* the DSL.
This benefits syntax like union, row value expressions (e.g. row(1,
2).in(select(A, B).from(T))), etc. When consuming these types in client
code, they can indeed get in the way. A lot of people will simply use
wildcards, or the generic Record type as a workaround:
Result<?> result = ctx.select(...).fetch();
for (Record record : ctx.select(...)) { ... }
Since Java 9, var is even better, as it allows for omitting the
declaration, locally, while not giving up on type safety:
var result = ctx.select(...).fetch();
for (var record : ctx.select(...)) { ... }
The quickest way to get named records in jOOQ would be to write views and
generate record types for them. In your case, you could write
CREATE VIEW rec_meter_lid_with_re_mbcd AS
SELECT real_estate.number, meter.id, meter.prod_core, meter.reading_serial,
meter.type, meter_bcd.id
FROM ...
Views are generally underappreciated in SQL, regardless if you're using
jOOQ or not. They're not at all contradictory to the jOOQ vision. Au
contraire. With the above view, you could now use the generated record type
in your jOOQ SQL:
Select<RecMeterLidWithReMbcdRecord> select =
ctx.selectFrom(REC_METER_LID_WITH_RE_MBCD);
Emitting types from ad-hoc queries would be great. In .NET, type providers
would allow this, and in Scala, I've played around with macros in the past
to achieve this. I don't think it is possible with vanilla Java annotation
processing, although we're observing some promising libraries and
approaches, including Manifold, which might allow for such tricks on a
lower compiler level than APT.
We could, of course, also implement some auxiliary APIs for quick wins like
yours, to help quickly define custom Record subtypes without implementing
them. In order to do that, I'd love to understand your use-case a bit more.
What is your expectation towards such a custom Record type? Why would you
use it?
Cheers,
Lukas
On Wed, Sep 18, 2019 at 7:57 PM Thorsten Schöning <[email protected]>
wrote:
> Hi all,
>
> I have a lot of SELECTs in which I only query individual columns of
> various tables, sometimes JOINed, sometimes not. In many of those
> cases the queries result in types with pretty long generic definitions
> of "RecordX<...>", like in the following example:
>
> > SelectConditionStep<Record6<String, Integer, MeterProdCode, String,
> MeterType, Integer>> select = this.getDbConn().getJooq()
> > .select(REAL_ESTATE.NUMBER,
> > METER.ID, METER.PROD_CODE, METER.READING_SERIAL,
> METER.TYPE,
> > METER_BCD.ID)
> > .from(FLAT)
> > [...]
> > .where(REAL_ESTATE.DELETED.isFalse())
> > [...]
>
> I would like to reduce that "Record6"-stuff to some better named
> custom type but don't understand how to do that without implementing
> all those interfaces defined by "Record", which already have been
> implemented by jOOQ. Neither RecordImpl, AbstractRecord or their
> counterparts for rows are publicly accessible or can be extended.
>
> Looking at things like "fetchInto" and "Record.into", I additionally
> have the feeling that I would be able to reduce "Record6"-stuff only
> in combination with actually fetching data. But I sometimes build
> queries spanning multiple methods and would like to get that
> "Record6"-stuff out of the way in those cases as well.
>
> The nearest thing I found was the following, which reads like fetching
> all columns of the tables part of the query in the end:
>
>
> https://www.jooq.org/doc/latest/manual/sql-execution/fetching/record-vs-tablerecord/
>
> What I would really like to do is simply creating a custom class or
> interface with very little boilerplate like a CTOR only or such,
> actually extending/implementing "Record6" and somehow reusing all the
> already available implementation of jOOQ. Than I would like to tell
> "select" that the indidvidual columns are actually of my custom
> records type and use that from than on.
>
> > SelectConditionStep<RecMeterLidWithReMbcd> select =
> this.getDbConn().getJooq()
> > .select(REAL_ESTATE.NUMBER,
> > METER.ID, METER.PROD_CODE, METER.READING_SERIAL,
> METER.TYPE,
> > METER_BCD.ID)
> > .from(FLAT)
> > [...]
> > .where(REAL_ESTATE.DELETED.isFalse())
> > [...]
>
> Is something like that possible? Thanks!
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: [email protected]
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
> --
> 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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jooq-user/13710196654.20190918195706%40am-soft.de
> .
>
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jooq-user/CAB4ELO6%2BVp7f0RJQk%3Dr5i53%2BZ4OXF9djYRLN5wsZYRYyax0jHg%40mail.gmail.com.
