Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    they support postgres ORMs from other languages
    Anton Ekblad
    @valderman
    it seems to use libpq for Go at least, which is what selda uses under the hood, so that shouldn't be an issue
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    I'm going to use CockroachDB's own debugging features, like audit logs and such
    Anton Ekblad
    @valderman
    that's probably the best way to go about it; the error selda throws when a query goes wrong contains pretty much all the info there is to be had from the db connection layer
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    yep

    (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"

    )

    Anton Ekblad
    @valderman
    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])
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    cool, I'm keeping that snippet for later
    :)
    Anton Ekblad
    @valderman
    having to keep the old table around is annoying, as you can see :P
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    yuup
    Anton Ekblad
    @valderman
    I have a pretty neat idea of how to get around that while still preserving type safety, and it's probably implementable as a much higher level selda-migrations library on top of the current migrations, but I haven't had the time to try it out in practice yet
    that config looks sound to me; extremely weird that it can't find the users table
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    yep'
    Al͜l ̸͑ha͂͟il̶!
    @TechnoEmpress_twitter
    blah
    I give up for tonight
    David Johnson
    @dmjio
    selda is great. Thanks @valderman
    Anton Ekblad
    @valderman
    @dmjio thanks! hopefully the upcoming changes in 0.4 will earn a stamp of approval as well; that stuff's been piling up for a while :)
    Alexander Gerasimov
    @DaQuirm
    hi
    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
    Anton Ekblad
    @valderman
    @DaQuirm not really elegant perhaps, but you could manually create instances for ID using toId and fromId
    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
    Alexander Gerasimov
    @DaQuirm
    Thank you, did just that :)
    Yes, it would be cool to have the instances out of the box, awesome!
    Anis Jonischkeit
    @anisjonischkeit
    Hey @valderman , I just tried installing from the latest version on hackage and it looks like SeldaM takes two parameters now. What's the additional one I need to include?
    Anis Jonischkeit
    @anisjonischkeit
    nevermind, I figured it out with:
    import           Database.Selda.PostgreSQL (PG)
    SeldaM PG a
    Alexander Gerasimov
    @DaQuirm

    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.5

    The 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!

    Anton Ekblad
    @valderman
    @DaQuirm: oops, that's me messing up the release! the version bounds on the -sqlite and -postgresql packages didn't get updated properly; I bumped the bounds on hackage, so hopefully it should work now after a cabal update
    sorry about that
    Alexander Gerasimov
    @DaQuirm
    it does work now, thank you! :+1:
    Andrei Dziahel
    @develop7
    Hi all; what would be the analogue of SELECT * FROM comments WHERE post_id = ? with Selda (given both comments and posts relation exist and comments' post_id is a FK relation to the posts.id)?
    Anton Ekblad
    @valderman
    @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
    Andrei Dziahel
    @develop7
    literal! thanks, @valderman
    Evžen Wybitul
    @Eugleo
    Hey guys!
    Evžen Wybitul
    @Eugleo
    Also, the OuterCols is a bit opaque. Could you explain whats the difference between them and normal Cols, and why are they needed?
    Evžen Wybitul
    @Eugleo
    Aaand — sorry that I'm bombarding you with questions — is it possible to have a SqlRow type such as Person = {name, age} and then another SqlRow type WithID a = WIthID (ID a) a and a table of WIthID Person?
    Evžen Wybitul
    @Eugleo
    (just in case, @valderman )
    Anton Ekblad
    @valderman
    @Eugleo OuterCols strips one nesting level from the scope of a bunch of rows or columns. For instance, OuterCols (Row (Inner s) a) = Row s a and OuterCols (Col (Inner s) a :*: Col (Inner s) b :*: ...) = Col s a :*: Col s b :*: ....
    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
    Evžen Wybitul
    @Eugleo
    @valderman Thanks! I'll look forward to the new version.
    Evžen Wybitul
    @Eugleo
    I've got one more question: is it possible to update a row in Table a with a, not having to specify exactly which columns are being rewritten?
    Anton Ekblad
    @valderman
    as in overwriting the entire row? not right now, but I just pushed a solution for the next release: valderman/selda#139
    Evžen Wybitul
    @Eugleo
    Yep, exaclty
    It's great that you already merged this into head; I'll clone the repo and use this immediately. Thanks!
    Evžen Wybitul
    @Eugleo
    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
    Evžen Wybitul
    @Eugleo
    Now that I think about it, it'd be cool if there was a way to build the predicate out of more things than just .==, .> and literals
    Evžen Wybitul
    @Eugleo
    I just found out about the operator from Unsafe, and as my backend (psql) supports ILIKE, my original problem is solved