Kamirus / purescript-selda

A type-safe, high-level SQL library for PureScript
MIT License
89 stars 3 forks source link

Allow newtype-wrapped columns #38

Open eviefp opened 4 years ago

eviefp commented 4 years ago

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:

newtype PersonId = PersonId Int
derive instance personIdNewtype :: Newtype PersonId _
derive instance personEq :: Eq PersonId

people ∷ Table
  ( id ∷ PersonId
  , name ∷ String
  , age ∷ Maybe Int
  )
people = Table { name: "people" }

bankAccounts ∷ Table
  ( id ∷ Auto Int
  , personId ∷ PersonId
  , balance ∷ Default Int
  )
bankAccounts = Table { name: "bank_accounts" }

qNamesWithBalance
  ∷ ∀ s. FullQuery s { name ∷ Col s String , balance ∷ Col s (Maybe Int) }
qNamesWithBalance =
  selectFrom people \{ id, name, age } → do      -- FROM people
    { balance } ← leftJoin bankAccounts          -- LEFT JOIN bank_accounts
                    \acc → id .== acc.personId   -- ON people.id = bank_accounts.personId
    restrict $ id .> lit 1                       -- WHERE people.id > 1
    pure { name, balance }                       -- SELECT people.name, bank_accounts.balance

So we're wrapping the person id in PersonId Int. Right now this gives an error on selectFrom people since it's looking for an Int but finding a PersonId. Ideally, it would work on any Newtype t Int by wrapping/unwrapping the values.

Would this be possible to implement? I might have a go, given some direction.

Kamirus commented 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 Newtyped 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
eviefp commented 4 years ago

Thank you, that works like a charm. I think that's pretty much all I wanted. :+1:

Kamirus commented 4 years ago

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)