Topic/java8

[jnizet]

This is a fix for #51.

It starts the new 2.0.0 release, including these changes, that make the new version not completely compatible with the latest 1.x version:

• Java 8 is now necessary. People still wanting to use Java 7 or Java 6 should stay on the latest 1.x release
• java.time classes are now supported. See the changes and the javadoc for details.
• the DateSequenceValueGenerator is now a generator of ZonedDateTime rather than a generator of Date. This should not have much impact though, because the old methods are kept (but deprecated), and typical usage should just need a recompilation
• Each time a Calendar or ZonedDateTime, or OffsetDateTime, or OffsetTime is passed, its timezone is honored by passing a Calendar with the timezone as third argument of setDate()/setTimestamp()/setTime(). This could have an impact for people using Calendars with a non-defaut time zone as argument, which, I guess, is quite seldom.
• The Binder returned by Binders.timeBinder()is now also used for columns of type TIME_WITH_TIMEZONE (which exists since Java 8)
• The Binder returned by Binders.timestampBinder()is now also used for columns of type TIMESTAMP_WITH_TIMEZONE (which exists since Java 8)

[clacote]

LGTM. Nice work!

[cexbrayat]

LGTM (except the versioning question)

[vaesbart]

Hi, I'm having trouble building the code (using NetBeans 8.1 / openSUSE Leap)

Stacktrace:

FAILURE: Build failed with an exception.

* What went wrong: Execution failed for task ':checkstyleMain'. > Unable to create a Checker: cannot initialize module Header - unable to load header file config/checkstyle/java.header

I'm not really familiar with gradle & it's config, but the file java.header is available on that location.

Is it possible to provide a jar in Maven central for testing ?

TIA Bart.

[jnizet]

Hi @vaesbart . Thanks for your feedback. I'll deploy a beta version to Maven and let you know about it. Probably tonight. In the meantime, if that's checkstyle that's bothering you, you should be able to just do ./gradlew jar to produce the jar without executing the tests and the static code analysis.

[jnizet]

@vaesbart DbSetup-2.0.0-beta1 is available in Maven central.

I haven't updated the user guide or published the javadoc online, but the javadoc, available from Maven, is up-to-date.

Thank you for telling me if everything is OK.

[jnizet]

@vaesbart have you had a chance to test the published beta version? Any feedback?

[vaesbart]

Yes, sorry it took so long for me to reply - real life and sudden illness got in the way...

I updated my test project with DbSetup-2.0.0-beta1 and replaced all java.util.Date's with new JDK8 LocalDate or LocalDateTime so everything compiles and looks OK but I get following error when trying to run a test class: java.sql.SQLDataException: An attempt was made to get a data value of type 'TIMESTAMP' from a data value of type 'VARBINARY'. I attached a small stacktrace :: dbsetup2_test.txt

I'm using jdk1.8.0_66 and its' included Derby database.

[jnizet]

@vaesbart No worries. I hope you're better now.

I'll paste the stack trace here for the record, and an easier to follow explanation:

Caused by: java.sql.SQLDataException: An attempt was made to get a data value of type 'TIMESTAMP' from a data value of type 'VARBINARY'.
    at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
    at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
    at org.apache.derby.client.am.ClientPreparedStatement.setTimestamp(Unknown Source)
    at org.apache.derby.client.am.ClientPreparedStatement.setTimestamp(Unknown Source)
    at org.apache.commons.dbcp2.DelegatingPreparedStatement.setTimestamp(DelegatingPreparedStatement.java:159)
    at org.apache.commons.dbcp2.DelegatingPreparedStatement.setTimestamp(DelegatingPreparedStatement.java:159)
    at com.ninja_squad.dbsetup.bind.Binders$DefaultBinder.bind(Binders.java:470)
    at com.ninja_squad.dbsetup.operation.Insert.execute(Insert.java:225)
    at com.ninja_squad.dbsetup.operation.CompositeOperation.execute(CompositeOperation.java:92)
    at com.ninja_squad.dbsetup.DbSetup.launch(DbSetup.java:107)
    ... 38 more

I don't know much about Derby, but reading the stack trace, it seems that it doesn't support parameter metadata. What does that mean? Normally, when inserting something in a column, DbSetup asks the database: what is the type of the column I'm going to insert somthing into? Then based on what the database returns, it chooses the best method to call: if it's a TIMESTAMP, then use setTimestamp(), etc.

For databases not supporting that feature, the default binder is used, and this uses a different technique. It looks at the value that is being inserted, and tries to guess the best way to insert that. So if you pass a LocalDateTime, DbSetup assumes that the underlying column is a TIMESTAMP (or compatible type), and calls setTimestamp().That's what happens here. Unfortunately, it seems that the column where you're trying to insert a LocalDateTime is of type VARBINARY.

That looks like a bug on your side to me: either the column is not correctly defined (i.e. doesn't have the right type), or you're not inserting the LocalDateTime in the corrrect column. If you really want to store a LocalDateTime into a column of type VARBINARY, you'll have to use a custom Binder to insert that value, because DbSetup can't guess how a LocalDateTime must be inserted into a VARBINARY column.

I hope that makes it clear.

PS: note that I released the 2.0.0 (non-beta) version now. So you should switch to that version (the code is identical to the beta).

[vaesbart]

Hi, I wanted to get back and explain why I got the above error. It was indeed a configuration error on my part. I'm using Hibernate to generate the database - when using JDK8 and java.time you need to declare hibernate-java8 as a dependency, so Hibernate generates Timestamp columns instead of Varbinary. Now everything works perfectly :)

[jnizet]

That's very nice of you. Thank you @vaesbart