ok now I'm understand why you don't use select *.
Compare live and generated sounds good. To achieve this I should compare
I'm going to do it.
This is very interesting and raise me into some other questions?
1. If I wrote this code could you integrate it into jooq ?
2. Using this function should be theoretically possibile to make a code
generation by difference, I mean generate only changed tables.
This is important to me cause my db is >1000 tables and generation is
Could be an interesting issue to open, isn't it?
Il giorno martedì 20 settembre 2016 10:58:40 UTC+2, Lukas Eder ha scritto:
> 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
> 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.
> 2016-09-20 8:29 GMT+02:00 Denis Miorandi <denis.m...@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
>> 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
>> 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
>> 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
>> 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
For more options, visit https://groups.google.com/d/optout.