Digest for jooq-user@googlegroups.com - 1 update in 1 topic

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Digest for jooq-user@googlegroups.com - 1 update in 1 topic

http://groups.google.com/group/jooq-user/topics mailing list
Lukas Eder <[hidden email]>: Sep 19 09:52AM +0200

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 <[hidden email]>
wrote:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].