Digest for jooq-user@googlegroups.com - 6 updates in 3 topics

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

Digest for jooq-user@googlegroups.com - 6 updates in 3 topics

http://groups.google.com/group/jooq-user/topics mailing list
Lukas Eder <[hidden email]>: Nov 20 12:30PM +0100

There currently isn't such a public API. There's a pending feature request
to help discover such things:
But I'm currently not sure if opening up such API is a good idea - it's
hard to keep the internal QueryPart APIs backwards compatible. Also, an
aliased field is quite a different thing from the original field reference.
For one, it can alias anything, including expressions based on several
field references and other expressions, such as:
first_name || ' ' || last_name AS name
Of course, you can keep a reference to your unaliased field and fetch the
qualified name from that:
Field<?> original = field( name( "MyTable", "myField" ) );
Field<?> aliased = original.as( "myAlias" );
String tableName = original.getQualifiedName().qualifier().last();
But I suspect the logic creating the alias is disconnected from the logic
referencing it.
As another workaround, you can use reflection on jOOQ's internals.
A third workaround would be to traverse the expression tree using a
VisitListener and introspect the individual parts being traversed...
I hope this helps,
[hidden email]: Nov 20 03:45AM -0800

Hi Lukas,
Thank you for your answer, I get it now why an alias sometimes shouldn't
have a reference to a table: even considering that some expression like
"'myvar' as myvar" is in context of some table, it is not really related to
the table by its nature.
I think I'll go with keeping a reference to the original field - it is
already kind of what I'm already doing.
Also it's nice to see that a lot of cases already have corresponding issues
on GitHub :)
On Monday, November 20, 2017 at 1:31:00 PM UTC+2, Lukas Eder wrote:
Lukas Eder <[hidden email]>: Nov 20 01:48PM +0100

> Also it's nice to see that a lot of cases already have corresponding
> issues on GitHub :)
Oh yeah - jOOQ has been around for a while, and so have been the various
ideas to enhance it. The question is just: Is there a more generic new
feature that would allow for solving dozens of issues at once, rather than
solving them individually :)
Lukas Eder <[hidden email]>: Nov 20 11:07AM +0100

Hi Serge,
Thanks for your message. That looks like an interesting case for "custom
code sections" in the code generator:
I could see a generated static method in the generated Schema class, which
does the switch for you. Something along the lines of:
public UpdatableRecord<?> newRecord(Configuration configuration, String
json) {
switch (...) {
case "type1":
UpdatableRecord<?> record =
// ...
return record;
Does that help?
[hidden email]: Nov 20 02:27AM -0800

That seems to do the trick!! Thanks a lot Lukas.
On Monday, 20 November 2017 11:07:44 UTC+1, Lukas Eder wrote:
Lukas Eder <[hidden email]>: Nov 20 11:11AM +0100

> My schema is dynamic, so I don't have any table-to-class mappings. And
> it's not possible to set such forcedType in a DSL config, is it?
Unfortunately, right now, it isn't - at least not for your particular
"plain SQL" / "direct JDBC" usage. The pending feature request is here,
I've increased its priority for jOOQ 3.11:
If you're willing to patch your jOOQ version, you will be able to implement
the feature directly in org.jooq.impl.MetaDataFieldProvider, which creates
Field<?> and DataType<?> references from JDBC's java.sql.ResultSetMetaData
I hope this helps,
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].