Closed paluh closed 5 years ago
Going for Aff (Either PGError a)
seems like the best option for interoperability with monad stacks. I think this question concerns those users who don't have a custom stack already. It boils down to whether we should give our own stack (the Database.PostgreSQL.PG
module) or mere helper functions and examples on how to create your own stack.
Going for Aff (Either PGError a) seems like the best option for interoperability with monad stacks. I think this question concerns those users who don't have a custom stack already.
I've added PG.hoist
and PG.hoistWith
helpers so even if a user have a custom moand stack it is quite usual to put ExceptT
as the last layer of such a stack and it can reuse some parts of existing PG
functionality just by hoisting to app stack.
It boils down to whether we should give our own stack (the Database.PostgreSQL.PG module) or mere helper functions and examples on how to create your own stack.
So, I think we are going to provide our stack as a starter.
Do you agree with code organization which you can find on the branch?
Database.PostgreSQL.PG
contains PG
related code.Database.PostgreSQL
contains core functoins and types (based on Either PGError a
). Yes, this sounds good!
@akheron I've done some simple code separation on
simple-core
branch.I'm thinking about two possible approaches to
PG
monad developement which we should clarify before the next release:We can keep it here but add a note in the docs that it is a bit experimental feature and that we need some real live scenarios to stabilize its API.
We can extract this monad into separate project and experiment there freely. Additionally we can point directly to this new project from this project README.
To be honest I prefer the first option a bit but I'm not sure if this approach is acceptable for our core library ;-)
What do you think?