> So, the bottom line is the Oracle JDBC driver does not care about > specification. Trying to set a number(1,0) field with a null value as > boolean throws an exception and there is not much we can do (excluding > registering an issue at oracle).
In this particular case, yes, Oracle doesn't properly implement PreparedStatement.setNull(index, Types.BOOLEAN) if the underlying data type is better described by Types.TINYINT. However, It is possible to let the driver "guess" the appropriate SQL type: PreparedStatement.setObject(index, null). The problem is that this change is quite delicate and would cause other parts of jOOQ to break. > As far as I remember, projects like Hibernate or Toplink Essentials > (followed by Eclipselink) do translate booleans to numbers before touching > JDBC, but maybe we should double check it. Yes, as long as jOOQ has the relevant information (e.g. when using converters), it knows that it really has to bind a "CAST(NULL AS NUMBER)", not "CAST(NULL AS BOOLEAN)". Forcing types to BOOLEAN without converters leads to jOOQ being ignorant of that fact. The "easiest" way of being database-agnostic in this case seems to be not to use the SQL BOOLEAN type in other databases, and model boolean values the same way across databases. Other users on this list may have made different experiences. Maybe Aaron Digulla has some insight? *@Aaron*: How do you guys deal with the SQL BOOLEAN type and jOOQ across your many supported database dialects? Cheers -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
