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.convertFromJdbc
passing 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?