Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

keep track of funding goal changes #141

Closed
chadwhitacre opened this issue Jul 12, 2012 · 10 comments
Closed

keep track of funding goal changes #141

chadwhitacre opened this issue Jul 12, 2012 · 10 comments

Comments

@chadwhitacre
Copy link
Contributor

I meant to make funding goal (#110) immutable like tips but forgot.

That is, it should be an insert into a "goals" table instead of updating a column in participants. Then we can show how funding goals evolve over time, which is an important part of telling the story in numbers.
This was referenced Oct 25, 2012
Closed
Closed
@chadwhitacre chadwhitacre mentioned this issue Feb 4, 2013
Closed
dowski pushed a commit to dowski/www.gittip.com that referenced this issue Mar 18, 2013
Initial support for funding-goals-over-time; gratipay#141
7a74b7a 
TODO:
 * Tests
 * Migration of current `goal` field to goals table entry for each user
 * Removing the `goal` column from participant
@dowski dowski mentioned this issue Mar 19, 2013
Merged
@dowski
Copy link
Contributor

dowski commented Mar 19, 2013

There is a goals table in the pull request linked above. When a new participant joins Gittip, should they automatically get an entry in that table with a NULL amount? Or is that to signify explicit user decision; "I am setting my goal to BLAH."; even if the explicit decision is the current NULL "I'm grateful yada yada" value.

@chadwhitacre
Copy link
Contributor Author

Per verbal discussion, let's go with the latter option (no goal entry until they explicitly make a decision).

@dowski
Copy link
Contributor

dowski commented Mar 19, 2013

Per verbal discussion, @whit537 is going to take it from here. He offered to write the migration SQL and I gladly accepted said offer.

@chadwhitacre
Copy link
Contributor Author

!m @dowski

Next steps:

  1. review and merge pull request
  2. take backup of db
  3. create goals table in production db
  4. insert initial data into goals table
  5. deploy new code There really isn't new code to deploy, now that we're using a rule (see 5e69c45).
  6. migrate data to goals table again, to pick up any changes
  7. drop goals column from participants

Step 6 is probably overkill for us.

@chadwhitacre
Copy link
Contributor Author

I've reviewed #745. See comments inline.

chadwhitacre added a commit that referenced this issue Mar 28, 2013
@chadwhitacre
Fix no-op typo; #141
97c1917
@chadwhitacre
Copy link
Contributor Author

I've merged #745 into a "goals" branch, which is pushed up here.

chadwhitacre added a commit that referenced this issue Mar 28, 2013
@chadwhitacre
Fix tiny format derp; #141
2223da0
@chadwhitacre
Copy link
Contributor Author

  • tests
  • review Participant.goal.set
  • /about/goals.html
  • SQL for migration

chadwhitacre added a commit that referenced this issue Apr 3, 2013
@chadwhitacre
Reimplement #141 using a Postgres rule
5e69c45 
Postgres has a feature called "rules," where we can rewrite queries
based on certain conditions. I've decided to implement #141 using a
rule. Starting with the example here:

  http://www.postgresql.org/docs/9.1/static/rules-update.html

this commit adds a rule to log changes to the participant.goal column to
a separate `goals` table. This means that we can keep the simplicity of
reading and writing that value as we've always done, *and* we can have a
detailed log of changes to drive more advanced visualizations.

Huzzah! :D
chadwhitacre added a commit that referenced this issue Apr 3, 2013
@chadwhitacre
Clean up Goal model a bit; #141
b67c222 
The Goal model is only needed right now by the test suite, and there
only to ensure that the database is torn down properly. I'm actually a
little nervous having this object around, because the `goals` table
should be considered immutable. Harumph.
chadwhitacre added a commit that referenced this issue Apr 3, 2013
@chadwhitacre
Move migration into a transaction; #141
ebb1c83 
This dodges a race condition where we could fail to log some goal
changes.
chadwhitacre added a commit that referenced this issue Apr 3, 2013
@chadwhitacre
Move new SQL to branch.sql; #141
90bbdd8 
Let's try out this pattern: feature branches should collect new SQL
statements in a branch.sql file, and if this exists we'll apply it
during makedb.sh. That should avoid some conflicts when merging from
master out to feature branches, as well as making it clearer that
branch.sql is a work in progress.
@chadwhitacre
Copy link
Contributor Author

I considered adding NULL records to the goals table for all participants (or perhaps all claimed participants) but decided against it. As with tips, let's use these log tables to record explicit events.

@chadwhitacre
Copy link
Contributor Author

Okay! The goals branch has landed on master! 1cc9eb2

chadwhitacre added a commit that referenced this issue Apr 3, 2013
@chadwhitacre
Move DDL for #141 from branch.sql to schema.sql
937da5d 
I've run this against the production database.c
@chadwhitacre
Copy link
Contributor Author

We did make one small code change with this, porting goals.json to use the ORM. That's now deployed. Case closed!

!m @dowski

chadwhitacre added a commit that referenced this issue Apr 3, 2013
@chadwhitacre
Oops, forgot to add changes to schema.sql; #141
4db1d3e
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dowski @chadwhitacre