On 07/31/2015 03: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
This isn't certain to be back-end accurate terms: I don't object strongly, but "share_value" still seems opaque. It isn't a value that is ever specified by itself, it just is a variable that is a synonym of ( num-active-patrons * min-pledge-level ), right? I think I'm okay with keeping it if it isn't confusing anyone else, but we need the definition to be really easy to find at least… > , 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. > > Not qualified to really weigh in, but Opaleye sounds great on the surface. Seems reasonable to me to keep it in mind and start using it / replacing things with it if it's better. As long as we keep all the Haskell functional / typed goodness, I'm all for whatever is smoothest. > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.snowdrift.coop/mailman/listinfo/dev > -- Aaron Wolf Snowdrift.coop <https://snowdrift.coop> _______________________________________________ Dev mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/dev
