Hello Christopher, > Your ticket seems to imply that you took a different approach: > silently ignoring the type incompatibility and return null instead. > > Am I missing something?
You got it right. org.jooq.tools.Convert tends to return null if a String to Number conversion fails. This ticket is about aligning String to Date/Time conversions with Numbers. Generally, jOOQ expects users to design their database with appropriate data types and constraints. If a number *must* be a number, then usually the offending data shouldn't even be inserted (i.e. it shouldn't be possible to insert "" in the first place). Hence, I chose this over throwing exceptions for convenience because if numbers and strings can be mixed in a database column (e.g. a properties table), then I assume the user knows what they are doing and they wouldn't want their SELECT statements to fail. Both points of view are viable, of course. The documentation and source is here: - http://www.jooq.org/javadoc/latest/org/jooq/tools/Convert.html - https://github.com/jOOQ/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/tools/Convert.java 2012/7/8 Christopher Deckers <[email protected]>: > Hi, > > https://sourceforge.net/apps/trac/jooq/ticket/1446 > > That ticket is interesting. I recently introduced an embedded > in-memory H2 DB in our product and I got bitten in some cases by the > fact that I was trying to convert an empty string to a number. This is > not legal of course and allowed me to find a bug (I wanted to store > NULL instead of empty string). > > Your ticket seems to imply that you took a different approach: > silently ignoring the type incompatibility and return null instead. > > Am I missing something? > > Cheers, > -Christopher
