Open eviefp opened 4 years ago
Hi @vladciobanu! Thanks for your interest!
I believe what you (almost) want is already implemented on the master branch, but the problem is that we haven't yet published it. Here is a link to the guide which explains how to deal with custom types just in case you've missed it
The error comes from the use of id .> lit 1
. So changing the lit
to handle Newtype
d values would do the trick - but this kind of implicit dispatch does not really fit IMO (partly because of the current experimental version of Lit on the scope-as-backend
branch which would not cope with it, I could elaborate on it more if want to hear more)
A simple solution is to use litPG
(it will change to just lit
eventually when we'll decide to commit to the changes on the scope-as-backend
branch)
...
restrict $ id .> litPG (PersonId 1)
and provide needed instances
instance toSQLValuePersonId ∷ ToSQLValue PersonId where
toSQLValue = un PersonId >>> toSQLValue
instance fromSQLValue ∷ FromSQLValue PersonId where
fromSQLValue = fromSQLValue >>> map PersonId
Thank you, that works like a charm. I think that's pretty much all I wanted. :+1:
Cool, anytime, always happy to help! ;)
I'll leave this issue open for now as I'd like to update the guide with an explicit 'newtype' example (and reference it in the basic guide)
Allowing newtype wrapped columns would be especially useful for (foreign) keys.
For example, it's easy to mistype and join on the wrong fields if they're all ints, but if we add a newtype, then this should be a lot safer. For example, I would love if this worked:
So we're wrapping the person id in
PersonId Int
. Right now this gives an error onselectFrom people
since it's looking for anInt
but finding aPersonId
. Ideally, it would work on anyNewtype t Int
by wrapping/unwrapping the values.Would this be possible to implement? I might have a go, given some direction.