spike out CouchDB for storing funds as json

[chadwhitacre]

Reticketing from #449. @MikeFair: Go ahead and assign this one to yourself to pick this up.

[MikeFair]

https://gist.github.com/4572217

[Replaced inline paste with link to gist. —ed.]

[MikeFair]

In the sample JSON file I made up above the "id" there is not the same as the official CouchDB document "_id".

There are 9 there documents in total.

I implemented each fund as one document completed with it's entries embedded in the document.
Unless someone else can see a compelling advantage, I see nothing gained by trying to split the entries into their own documents.

As a quick start prototype, check out to the JSON map the fund ids -> Child item ids:
http://test-garden20-8sj9.iriscouch.com/donations/_design/gt/_view/funds

Then check out to see [Resource/Currency, Fund ID, Child ID] -> shares:
http://test-garden20-8sj9.iriscouch.com/donations/_design/gt/_view/fundsums?group_level=3

Then check out to the shares version reduced down to weights (aka percentages):
http://test-garden20-8sj9.iriscouch.com/donations/_design/gt/_list/weights/fundsums?group_level=3

What I don't have working at the moment here are the steps to further reduce the child IDs until the only thing left are direct user ids and a cumulative percentage based on the whole hierarchy.

For the moment, it simply takes each fund document and creates a percentage weight of its entries.

[chadwhitacre]

This is more complex than the simple example on https://github.com/zetaweb/www.gittip.com/issues/449#issuecomment-12330669, though you're almost certainly right that we're going to want more info in there. Can we come back to this when we have the UI and API spec'd out further?

[MikeFair]

After some initial experiments and some good results, I hit a wall when I went to calculate the percentages iteratively. It turns out that to do the recursive iterations Map/Reduce isn't well suited to the kinds of operations I was trying to do. :)

After talking to some folks, reading some blogs, and pouring over a few different web sites.
What we really want ultimately here is a graph database like neo4j - and it turns out that heroku has an add-on.

I've no experience doing graph based queries, so that's not so good - however the neo4j folks have put together some great tutorials and some nice query languages, so that's good again.

I'm going to take a two phase approach here:
Phase 1) Make groups work in Postgres using Common Table Expressions and the WITH RECURSIVE keyword.
Should be extremely straightforward/simple but I'll need to get the DB schema for where the current gifts/amounts are stored
Phase 2) Experiment with neo4j to make it work there. Having the data in neo4j once figured out is going to be awesome.