Closed abigailalice closed 1 year ago
Thanks for reporting this. I'm pretty sure this is just an oversight on my part. I'll patch this in a new release soon, but in the meantime you might like to use unsafeCoerceField
to work around it.
Should be fixed in https://hackage.haskell.org/package/opaleye-0.9.4.0. Let me know if this doesn't solve the problem for you.
Oops, actually fixed in https://hackage.haskell.org/package/opaleye-0.9.4.1
I just upgraded to a more recent version of Opaleye, and noticed that these types were changed from
SqlOrd b => (a -> Column b) -> Order a
toSqlOrd b => (a -> Field b) -> Order a
, and don't understand why these types were made more restrictive. This was changed in c5d5b5094847f52267821029cb2af3fd0f242537, but I don't see how the types could actually allow the different ordering based on nulls to even be exposed to the database, since the projection function will necessarily have to have removed the null before the value actually gets sorted, and thea
could be a record with multiple null fields.I have a record representing a database row which contains a
FieldNullable SqlDate
, but unless I'm failing to see something very simple I couldn't see how to achieve the old behaviour without doing something likeO.asc $ O.matchNullable (O.toFields (ModifiedJulianDate largeNegativeInteger)) nullFieldSelector
, which isn't even really achieving the old behaviour in the first place.I'm not sure if #545 might possibly be related longterm, if
FieldNullable
ever becoming deprecated implies anything forField_
. I also noticed the type ofmatchNullable
was made more restrictive as well (not allowing aFieldNullable
to be returned, when previously it did), so I'm still kind of figuring out the results of usingMaybeFields (Fields a)
in practice.