Hi Denis,

Thank you very much for your question. Excellent SQL standard document
style definition of T1, C1, C2, etc. :)

That's a very interesting question. I believe that somewhen in the past,
there had been a similar enquiry on this mailing list where someone solved
the problem by comparing the jOOQ meta data with the production schema. You
can do this by comparing:

- MY_GENERATED_SCHEMA.getTables() and then fields()
- DSLContext.meta().getTables()

That could be run as some sort of integration test or smoke test. Another
option would be a nightly build that re-generates the jOOQ schema and
compares the nightly build's version's Java code (or byte code) with the
version that is checked in in version control and running in production.

Another option will be available in jOOQ 3.9, when it will be very easy to
export meta data information in XML format, which is much easier to compare
than Java source code or byte code. Some example issues:

- https://github.com/jOOQ/jOOQ/issues/5347
- https://github.com/jOOQ/jOOQ/issues/5437

Indeed, you mentioned "typesafe mode with select *" - by that you probably
mean using DSLContext.selectFrom(), which returns generated records instead
of the untyped org.jooq.Record. In that case, you cannot automatically
check column names explicitly.

Probably I should better know the engine behavior, but I'm wondering about
> why jooq does not render T1.* instead exploding fields.


The reason is because jOOQ will expect exactly the columns that are
available from the generated record and optimises fetching them by using
access-by-index rather than access-by-name. If T1.* was generated in the
SQL statement, you would only defer the problem until later. It's usually
desireable to have this query fail early.

You could force jOOQ to generate a SELECT * query and discover the actual
columns from the actual result set meta data if there's at least one
"unknown" table (i.e. plain SQL table) in the FROM clause. But that's
generally not desireable.

Btw in a full jooq environment this is not an issue, but legacy code
> exists...


Sure, I perfectly understand this.

I hope you've found my ideas useful. I'm sure there are other ideas too, to
detect this issue as early as possible.

Lukas

2016-09-20 8:29 GMT+02:00 Denis Miorandi <denis.miora...@gmail.com>:

> hi Lukas,
>    we have a mix of jooq (mine) and legacy non jooq (aka string queries)
> code in production.
>
> Sometimes happens that :
>
> let *T1* be a table and *C1,C2* it's column.
> let *JAPP* be a jooq app that use T1.C1
> let *LAPP* a legacy APP that use T2.C2
> let T1 be shared between *JAPP and LAPP*
>
>
> Suppose a developer on LAPP rename T1.C2==>T1.C3 and don't care about put
> in production jooq generated code.
> Now JAPP is broken cause when jooq generate query on whole table it
> generate
> create.select().from(T1) ==> SELECT FROM T1.C1, T1.C2, *but T1.C2 was
> renamed to T1.C3*
>
> The issue is that JAPP does not use directly T1.C2 in code so neither an
> automatic build could solve this problem due to dynamic nature of select
> fields.
> Probably the only compatible/working solution should be to generate select
> T1.*, but seems that jooq can not work in typesafe mode with select *.
>
> Probably I should better know the engine behavior, but I'm wondering about
> why jooq does not render T1.* instead exploding fields.
> Btw in a full jooq environment this is not an issue, but legacy code
> exists...
> Have you got any ideas how to avoid this issues?
>
>
>
> --
> 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 jooq-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 jooq-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to