plumb takes

[chadwhitacre]

⬑ #3994

← #4070 — #4024 →

Punchlist

• Takes determines → Takes determine
• There is no Membership mixin yet (docstring).
• require working payout route
• add recorder to both methods
• upgrade ntakes to bigint
• prevent the owner from claiming takes (they get baseline and unclaimed) plumb takes #4023 (comment)
• update participants.taking
• move cacherinoes into Postgres (triggers) nevermind → rationalize computed values #4064
• prune the old _mixin_teams.py file
• handle takes during take_over
• remake against master once use source order for docs #4070 lands

[chadwhitacre]

prevent the owner from claiming takes (they get baseline and unclaimed)

Actually, let's leave this up to the teams to decide, ya?

[chadwhitacre]

I want to handle takes during take_over as with identities: hard-failing (we really should already be failing for or otherwise handling the case where one account takes over another that owns one or more teams). The easiest way to handle this will be with a check for other.ntaking_from > 0, so that gets back to the other open item on the punchlist: updating taking and ntaking_from. Since takes are proportional now instead of absolute, changes to one person's takes affect the taking of all other members of the team, plus the owner. Working it through ...

[chadwhitacre]

ntaking_from is easy. It's taking that's difficult.

[chadwhitacre]

Bringing over here from #3994 (comment) ...

I'm working on writing update_taking as a PL/pgSQL function, because I don't see how to write it in Python without too many database calls.

---

Looks like we can do it in Python and write back to the database once per team with this mechanism.

Now we're thinking we might try with trigger functions on UPDATE in Postgres.

[chadwhitacre]

What needs to change when?

on INSERT into takes

• for the participant:
  • ntaking_from
  • taking
• for team mates:
  • n/a
• for the owner:
  • n/a
• for the team:
  • ndistributing_to
  • distributing
  • surplus

on UPDATE of teams.receiving

• for the owner:
  • taking
• for all members:
  • taking
• for the team:
  • distributing
  • surplus

[chadwhitacre]

Cached values updates in triggers is looking promising: 3fb940a.

[chadwhitacre]

Following in the illustrious lineage of cached values work #3599, #3721, and #3729 ...

We're now experimenting with calling them "computed" values as opposed to ... what? "Primary" values? "Original" values? "Real" values? "Independent" values? "Assigned" values? "Root" values? "Input" values? "Raw" values? "Observed" values? "Given" values?

Here are the four given values:

i	name	property of	description
1	payment instruction	participant	amount of money the participant intends to pay a given team, weekly
2	baseline	team	threshold below which no money will be distributed in any given week
3	takes issued	team	total number of parts into which money available for weekly distribution will be divided
4	takes claimed	participant	number of parts of a given team's weekly distribution of money that the participant intends to collect

All the other numbers we care about can be computed from those four:

i	name	property of	function
1	giving	participant	sum of payment instructions from the given participant
2	ngiving_to	participant	number of payment instructions from the given participant
3	receiving	team	sum of payment instructions to the given team
4	nreceiving_from	team	number of payment instructions to the given team
5	claimed takes	team	sum of takes claimed from the given team
6	unclaimed takes	team	takes issued - claimed takes
7	distributing	team	(claimed takes / takes issued) * (receiving - baseline)
10	ndistributing_to	team	count of takes claimed for the given team
11	surplus	team	receiving - baseline - distributing
7	taking	participant	(sum of (takes claimed / takes issued) * (receiving - baseline) for all memberships) + ((min(receiving, baseline) + surplus) for all ownerships)
8	ntaking_from	participant	count of (takes claimed by the given participant ∪ ownerships)

---

given values are bold
computed values are in italics

[mattbk]

"Computed values" makes much more sense to me than "cached values" for this sort of thing, FWIW.

"Entered values"?

[chadwhitacre]

"Computed values" makes much more sense to me than "cached values" for this sort of thing, FWIW.

Cool. 👍

"Entered values"?

Hmm, maybe ...

[chadwhitacre]

We may also want to work "take" into the chart, as the dollar amount a given participant is collecting from a given team.

[chadwhitacre]

@mattbk Nice! @kaguillera and I were saying we should make a graph. :-)

Could also throw it in http://interactive.blockdiag.com/?

[mattbk]

Not sure if blockdiag shows things the same way; the overlapping lines are confusing.

EDIT: different syntax

[chadwhitacre]

Yeah, that's definitely less clear.

[kaguillera]

!m @mattbk

[chadwhitacre]

Rebased, previous head was 3fb940a.

[chadwhitacre]

Based on #3994 (comment), for simplicity's sake let's assume for now that a Team will always have enough to cover the amount they're making available for payouts each week. This should be sufficient for #3994, at least.

[chadwhitacre]

Scrapping for parts.