After migrating to 0.9.6, I have this typical custom type for joda's LocalDate:
implicit val jodaLocalDateTEF = new NonPrimitiveJdbcMapper[java.util.Date, LocalDate, TDate](dateTEF, this) {
def convertFromJdbc(v: java.util.Date): LocalDate = new LocalDate(v.getTime)
def convertToJdbc(v: LocalDate): java.util.Date = new java.util.Date(v.toDateTimeAtStartOfDay.getMillis)
}
implicit def jodaLocalDateToTE(ld: LocalDate): TypedExpression[LocalDate, TDate] =
jodaLocalDateTEF.create(ld)
implicit val optionJodaLocalDateTEF = new TypedExpressionFactory[Option[LocalDate], TOptionDate] with DeOptionizer[java.util.Date, LocalDate, TDate, Option[LocalDate], TOptionDate] {
val deOptionizer = jodaLocalDateTEF
}
implicit def optionJodaLocalDateToTE(old: Option[LocalDate]): TypedExpression[Option[LocalDate], TOptionDate] =
optionJodaLocalDateTEF.create(old)
The problem is that I have a class C with an attribute of type Option[LocalDate], and when I query a row with that value set to NULL, I find Squeryl calling jodaLocalDateTEF.convertFromJdbcpassing null.
It looks like Squeryl is ignoring my deOptionizer and this fails with an error like this:
could not map row :
ResultSetRow:[#1->1:Long,#2->null:Date]
with mapper :
'ResultSetMapper:1a45193b($(1->C.id:java.lang.Long),$(2->C.TEST_DATE:Option[org.joda.time.LocalDate]))--*
By looking at the error message, the colum seems to be correctly recognized as Option[LocalDate], however, as I mentioned before, Squeryl calls the mapper directly instead of checking first whether it should. How can I troubleshoot why Squeryl is behaving this way?
What I see (and suspect) so far is that in FieldMetaData.setFromResultSet, the resultSetHandler seems to be invoked first (which also calls the mapper), and then FieldMetaData.set is called, which finally checks whether the value is null and the target type is Option.
Could this be a bug in the 0.9.6 version or am I doing something wrong in my custom type mapping?