I'd probably drop down to postgres-simple and run that query as is. I don't think the lack of typing needs to be a deal breaker if it's going to be easier to write and easier to test.
Opaleye does seem really nice, I've been looking forward to playing with it On Fri, Jul 31, 2015, at 12:17 PM, Bryan Richter wrote: > On Thu, Jul 30, 2015 at 05:18:00PM +0300, Nikita Karetnikov wrote: > > I have to admit the current mechanism implementation makes me uneasy. > > Everything is mutable and some functions, like underfundedPatrons, do > > too much, making it hard to test and even follow. > > Incidentally, where's what I would like underfundedPatrons to "look" > like: > > select * from ( > select pl.user > , balance - (outlay.tot - (funded_shares * share_value)) as > avail > , pr.id as project > , pr.share_value > , pl.funded_shares > , ac.id account > from pledge pl > join "user" u on pl.user = u.id > join account ac on ac.id = u.account > join project pr on pl.project = pr.id > join ( > select u.id as user, sum(funded_shares * share_value) as tot > from pledge pl > join project pr on pl.project = pr.id > join "user" u on pl.user = u.id > join account ac on u.account = ac.id > group by u.id > ) outlay on outlay.user = u.id > ) as q > where avail < share_value * funded_shares > order by q.user > > This is a "pure" function of the underlying tables (except perhaps for > the use of share_value, which is strictly speaking non-normalized and > thus spooky). It could be easily tested in isolation. The subquery "q" > could be turned into a database view and thus encapsulated. > > The problem is I don't know how to interface this query with the > Haskell code, yet. I would very much like to. Thanks to years of > experience, I can write queries like this in a matter of minutes, but > it still takes me hours to hammer them into the persistent/esqueleto > mold. > > I also want compile time guarantees (types). There's a un(i)typed > multiplication in there between funded_shares and share_value that > should be a compile-time error. The sum itself is another potential > type error, since in general it could return null (Nothing) — although > I think it never will in this case. I should also be able to ensure > that every use of this query expects the correct result types. > > So... any thoughts? For now I think I'll just crash through some more > persistent and esqueleto to end up with the equivalent data. If anyone > wants to look into this, though, I'm pretty sure you'd get good > support from upstream. > > -*-*-*- holy crap -*-*-*- > > This is what I want: > > https://github.com/tomjaguarpaw/haskell-opaleye > > Using Opaleye would probably require some deep restructuring of the > Snowdrift Model code, so I'll hold off for now. I do hope we can move > towards using it, though. > _______________________________________________ > Dev mailing list > Dev@lists.snowdrift.coop > https://lists.snowdrift.coop/mailman/listinfo/dev > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) _______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
