(for what it's worth, I've also got this configuration:
λ❯ pgConnString . connectInfo $ config
"host=localhost port=26257 dbname=defaultdb user=euphrate connect_timeout=10 client_encoding=UTF8")
as for migration examples, there's not much to it; you need to give the source and destination tables as well as a selda expression to convert a row from the source table into one for the destination table, so something like this:
data User1 = User1 {name :: Text, password :: Text}
t1 :: Table User1
t1 = table "user" []
data User2 = User2 {name :: Text, password :: Text, age :: Int}
t2 :: Table User2
t2 = table "user" []
main = withPostgreSQL $ migrate t1 t2 (\user -> user `with` [#age := 0])
:)
that config looks sound to me; extremely weird that it can't find the users table
I give up for tonight
hi
I'm building my first app with selda and I ran into a problem: I'm using the
Any elegant way to solve this?
Thanks!
@valderman
I'm building my first app with selda and I ran into a problem: I'm using the
ID type in my entity and that prevents me from deriving generic aeson instances for it (as there appears to be no aeson or generic instances for ID).Any elegant way to solve this?
Thanks!
@valderman
also, not having those instances are a bit of an oversight, so I'll make a new release soonish which adds
Generic instances in selda, and To/FromJSON in selda-json
Hej @valderman
I'm trying to migrate to selda-0.5.0.0 but stack refuses to build selda-postgresql:
❯ stack build
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for selda-postgresql-0.1.8.0:
selda-0.5.0.0 from stack configuration does not match >=0.4 && <0.5The dependency seems to be listed correctly in the cabal file in the repo (< 0.6):
https://github.com/valderman/selda/blob/master/selda-postgresql/selda-postgresql.cabal
But it's still 0.4 as seen on Hackage:
https://hackage.haskell.org/package/selda-postgresql
Thanks!
sorry about that
@develop7 the most straightforward way would be something like this: https://gist.github.com/valderman/d61d245dc47017e1addfb603d830f6cb
either the function starting on line 29 or the one starting on line 36
it's a bit contrived, but the scope parameter is needed to ensure that values don't accidentally leak into subqueries where they are not in scope and
OuterCols is there to handle gracefully sharing values between scopes where it's safe to do so
as for the second question, that's currently not possible (row types can't be nested), but there's nothing fundamental preventing us from supporting it and we probably should
I don't know when I'll have the time to work on it, but if you open an issue about it at least it'll be in the backlog
oh wait, I see you already did :P
as in overwriting the entire row? not right now, but I just pushed a solution for the next release: valderman/selda#139
It's great that you already merged this into head; I'll clone the repo and use this immediately. Thanks!
Hey, me agan! I wonder what's the best way to restrict rows based on a case-insensitive value in one of the columns, e.g. something like:
--- table =
--- id | name
--- 0 | Anton
--- 1 | anton
names = query $ do
user <- select table
restrict $ LOWER(user ! #name) `like` "%a%"
return $ user ! #name
-- names is ["Anton", "anton"]
Without
LOWER, it outputs only ["anton"], understandably. I could construct multiple search strings manually to permute all different letter cases, make predicates from each individual one, and then join those predicates with .||, but that sounds quite laborious