The added complexity of beam is non trivial. I would argue that the benefit doesn't outweigh the cost
so far I haven't used even the first orm, relational algebra, DSL, edsl etc that wouldn't have at some point leaked the abstraction, or support some necessary part of sql, or generated horrible sql etc
Yeah, hasql is nicer than PG simple in my eyes. Not abusing typeclasses for encoding / decoding stuff makes it pretty excellent and painless to deal with. :heart:
yes, that's a positive aspect I also noticed when perusing the Beam docs.
I've been playing around with deriving Row and Params for my types, which works pretty fine, but it's a bit tedious that I can't (afaict) simply run those codecs for testing
my experience with codecs has often been that it's undesirable when the data type has to incorporate stuff for derivation in its fields, like the Columnar in Beam
though looking at my code now I realize that the most significant parts of the derivations deal with the constructions of statements, the codecs are rather trivial
You know, hasql is not something I've ever really tried. IIRC you still write raw sql queries on it, but define the encoders/decoders with functors / contravariant functors instead of typeclasses. So I would liken it with postgresql-simple. The full power of SQL with the type safety of haskell where it matters the most.
Personally I haven't had any pain with having type classes as encoders (like psql, aeson, quickcheck), but I've seen plenty of people having pain with it
tfw when constraints are longer than the function body image.png
this is the dream
each of those constraints is writing code for you :)
I'm not a friend of beam, but tbh, those constraints tell me more about what the function does than the implementation
@Mats Rauhala why do you not like Beam? what do you prefer?
I would just go with postgres simple.
Instead, I endorse writing a simple function with a clean type and writing some tests for it.
addPerson :: WithDB r m => Person -> m ()
Of course, when your purpose is to learn something new or have fun, go with what you want
ok, I have only used Hasql so far, I guess that comes with a similar cost
Yeah, hasql is nicer than PG simple in my eyes. Not abusing typeclasses for encoding / decoding stuff makes it pretty excellent and painless to deal with. :heart:
yes, that's a positive aspect I also noticed when perusing the Beam docs.
I've been playing around with deriving
RowandParamsfor my types, which works pretty fine, but it's a bit tedious that I can't (afaict) simply run those codecs for testingmy experience with codecs has often been that it's undesirable when the data type has to incorporate stuff for derivation in its fields, like the
Columnarin Beamthough I still use
generics-sop, so that's kind of similar, only more generalthough looking at my code now I realize that the most significant parts of the derivations deal with the constructions of statements, the codecs are rather trivial
You know, hasql is not something I've ever really tried. IIRC you still write raw sql queries on it, but define the encoders/decoders with functors / contravariant functors instead of typeclasses. So I would liken it with postgresql-simple. The full power of SQL with the type safety of haskell where it matters the most.
Personally I haven't had any pain with having type classes as encoders (like psql, aeson, quickcheck), but I've seen plenty of people having pain with it