Rails 5.0 app crashes in setDateParameter with Java exception IllegalArgumentException

[haohaolee]

Hi folks,
We are upgrading our jruby rails app from 4.2 to 5.0 now, and encountered a weird issue. This issue is about an java exception from the Date type conversion in the postgresql jdbc adapter:

Java::JavaLang::IllegalArgumentException ():
  
java.sql.Date.valueOf(Date.java:143)
arjdbc.postgresql.PostgreSQLRubyJdbcConnection.setDateParameter(PostgreSQLRubyJdbcConnection.java:370)
arjdbc.jdbc.RubyJdbcConnection.setStatementParameter(RubyJdbcConnection.java:2630)
arjdbc.jdbc.RubyJdbcConnection.setStatementParameters(RubyJdbcConnection.java:2592)
arjdbc.jdbc.RubyJdbcConnection$11.call(RubyJdbcConnection.java:971)
arjdbc.jdbc.RubyJdbcConnection$11.call(RubyJdbcConnection.java:960)
arjdbc.jdbc.RubyJdbcConnection.withConnection(RubyJdbcConnection.java:3510)
arjdbc.jdbc.RubyJdbcConnection.withConnection(RubyJdbcConnection.java:3476)
arjdbc.jdbc.RubyJdbcConnection.execute_insert_pk(RubyJdbcConnection.java:960)
arjdbc.jdbc.RubyJdbcConnection$INVOKER$i$execute_insert_pk_DBG.call(RubyJdbcConnection$INVOKER$i$execute_insert_pk_DBG.gen)
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodTwoOrThree.call(JavaMethod.java:1324)
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:837)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:332)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:86)
org.jruby.ir.instructions.CallBase.interpret(CallBase.java:552)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:361)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:116)
org.jruby.runtime.InterpretedIRBlockBody.commonYieldPath(InterpretedIRBlockBody.java:140)
org.jruby.runtime.IRBlockBody.yieldSpecific(IRBlockBody.java:70)
...

The relevant gems are:

    activerecord-jdbc-adapter (50.6-java)
      activerecord (~> 5.0.0, >= 5.0.3)
    activerecord-jdbcpostgresql-adapter (50.6-java)
      activerecord-jdbc-adapter (= 50.6)
      jdbc-postgres (>= 9.4, < 43)

This issue is all about the Date type conversion, we think the cause of this issue is because we have a

Date::DATE_FORMATS[:default] = '%b-%d-%Y'

in some initializer, which leads to the wrong conversion in PostgreSQLRubyJdbcConnection.java:370:

activerecord-jdbc-adapter/src/java/arjdbc/postgresql/PostgreSQLRubyJdbcConnection.java

Lines 359 to 370 in f4018da

	@Override
	protected void setDateParameter(final ThreadContext context,
	final Connection connection, final PreparedStatement statement,
	final int index, IRubyObject value,
	final IRubyObject attribute, final int type) throws SQLException {
	if ( ! "Date".equals(value.getMetaClass().getName()) && value.respondsTo("to_date") ) {
	value = value.callMethod(context, "to_date");
	}
	// NOTE: assuming Date#to_s does right ...
	statement.setDate(index, Date.valueOf(value.toString()));

We changed the default to_s for Date type from its default ISO8061 yyyy-mm-dd format.

But somehow it works for our 4.2 codebase, so we are wondering if this is something that needs fixing in 50-stable branch for AR-JDBC

ps: I noticed there are some changes for this file in 52-stable branch which seems fixed for this issue...

To reproduce this issue, you can just use rails scaffold to create a model to include date type and change Date::DATE_FORMATS[:default] to something other than ISO8601, then insert some record.

Thanks very much

[dr-itz]

Thanks for the report and debugging the problem! I back-ported the code from 52-stable in #1062.

[headius]

Probably not a lot of churn happening on the 5.0 branch... maybe we can spin a release to help our friend here? cc @enebo @kares

[enebo]

yeah I will do a release of 50-61 as I think a few other things have been fixed on newer versions since mid december (last releases).

Technically 50.x is no longer supported. @haohaolee I recommend updating to a newer Rails sooner than later. Eventually we want to get to same policy as https://guides.rubyonrails.org/maintenance_policy.html.

With that said, the time it takes to release 3 releases vs 5 releases at this point is not significant. So long as simple compat fixes come in I do not have a problem with extra releases. I also know it is difficult for Rails uses to skip past significant Rails releases and incrementally update.. So we are sympathetic.

[enebo]

@haohaolee I put out a new release today. Hopefully things are working for you once you update.