[ANNOUNCEMENT] Version 3.8.5 released with various fixes

[Lukas Eder]

Version 3.8.5 - October 21, 2016

================================================================================

This is a patch release with some useful fixes for the 3.8 branch

Features and Improvements

-------------------------

#5454 - Add a big disclaimer to the Mock API not to mock an entire database

#5534 - Mention the possibility of running SELECT * by keeping an empty select() field list

#5565 - Log warnings when users misconfigure forceType / customType elements

#5566 - Improve DSLContext.batchStore() Javadoc

#5606 - Code generator should delete catalog and schema directories when no longer configured

Bug Fixes

---------

#5427 - Don't escape Scala-style setter names produced by naming strategies in ScalaGenerator

#5447 - Unnecessarily costly query to check for Oracle version in code generation

#5458 - "overriding method fields in class AbstractRecord" compilation error when using ScalaGenerator on tables containing columns like "fields", "configuration", etc.

#5465 - Wrong @Support annotations on DSL.sequence() constructors

#5482 - ResultImpl#intoMap produces an incorrect error message on duplicate key

#5496 - NotSerializableException thrown when AbstractXMLasObjectBinding is applied on a column

#5500 - Cannot apply Binding to PostgreSQL UDT arrays

#5523 - Bad SQL generated for PostgreSQL when inlining arrays

#5531 - Don't System.exit(-1) from within GenerationTool. Throw an exception instead

#5548 - Work around an ojdbc7 driver bug producing a NPE for Oracle 12c INSERT .. RETURNING statements

#5560 - Compilation error when generated catalog and one of its contained schemas have the same name

#5572 - DataTypeException: Cannot convert from String to class [B when generated code contains VARBINARY type with default value

#5579 - Incorrect ambiguity warning when column name appears in 3+ joined tables

#5580 - NullPointerException when generating Oracle AQs with payload types outside of the included schemas

#5598 - Code generator IOExceptions are not logged when error appears during closing of file

#5599 - Error on code generation when schema name is a Windows reserved name like CON, AUX

#5610 - JPADatabase includes undesired INFORMATION_SCHEMA by default

#5611 - JPADatabase causes warnings

#5615 - SchemaVersionProvider might cause deletion of schemas that were not updated

[Denis Miorandi]

I'm interested on #5534, but I don't understand if is closed cause it's implemented or just mentioned.

If yes how is possible to achieve that behavior? Some configurations?

Tks

Denis

[Lukas Eder]

Hi Denis,

The issue title might be a bit incomplete. It should have stated "mention in the Javadoc". You can see the change here:

http://www.jooq.org/javadoc/latest/org/jooq/DSLContext.html#select-org.jooq.SelectField...-

Hope this helps,

Lukas

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

[Samir Faci]

I'm curious when was that feature introduced? Turning an empty list into a select * I mean. 

[Lukas Eder]

Probably jOOQ 1.0 :)

(because, what else could it mean?)

[Samir Faci]

I think I may not be understanding the intended behavior then.

given a table with something along these lines

user_table:::   first_name, last_name, address, hire_date... etc

if I do:

dslContext.selectFrom(USER_TABLE)  or dslContext.select().from(USER_TABLE)  or dslContext.select(ImmutableList.of()).from(USER_TABLE) 

The SQL generated expands to:

select  first_name, last_name, address, hire_date from user_table rather then select * from user_table.

In some cases I'd rather do a select * it avoids issues where our JAR has fields that haven't made it out to production yet that snuck into a build inadvertently.

(Granted we should be testing this but I find select * to be safer).

Is there a way to prevent Jooq from exploding * to the list of all known fields?

--

Samir Faci

Thank you
Samir Faci

https://keybase.io/csgeek

[Lukas Eder]

Hi Samir,

Oh, I see. I suspect that Javadoc should still be further improved. If jOOQ can figure out the expected column list from the FROM clause, it will actually generate it.

There are two pending feature requests for forcing the generation of asterisks:

- unqualified: https://github.com/jOOQ/jOOQ/issues/2769

- qualified: https://github.com/jOOQ/jOOQ/issues/1677

But you can also work around this limitation by "hiding" the table list from jOOQ. This can be done most easily by using plain SQL:

ctx.select().from("{0}", USER_TABLE)

Now, since jOOQ has no idea what columns will be returned, it will render SELECT * FROM user_table.

Hope this helps,

Lukas