Fake data - subscriptions and payments #3596
Conversation
| if participant.username == team.owner: | ||
| direction = 'to-participant' | ||
| else: | ||
| direction = random.sample(['to-team','to-participant'],1)[0] |
There was a problem hiding this comment.
Since we don't have takes yet - If the participant isn't an owner, the direction will always be to-team.
There was a problem hiding this comment.
Also, since teams don't carry a balance - we need the net payments to sum up to zero. I've added a db check for this in #3597 :) Maybe try rebasing on that to make sure?
rorepo
force-pushed
the
fake-data-subscriptions-and-payments
branch
from
cb0655a to
e2aaae7
Compare
|
The requirement of payments adding up to zero for teams is unlikely to be met with the random values being created at the moment. Therefore, this will require the following approach:
This will however have the effect of limiting the number of payments to no. of participants * no. of teams. |
|
Logic modified as above. The number of subscriptions is also now dependent on the number of participants and teams, unless we are to go for multiple subscriptions from the same participant to the same team. |
|
@rorepo Quick note re: process: Please apply the "Review" label to PRs that are ready for review. (I've updated http://inside.gratipay.com/howto/label-github-issues; waiting for the change to propagate.) |
|
The teams are created, but I can't see them on the Explore page...
|
|
Oops, sorry - My bad. A server restart fixed it. |
rohitpaulk
force-pushed
the
fake-data-subscriptions-and-payments
branch
from
2633edc to
1d00bf4
Compare
|
Rebased on master. |
|
@techtonik - Any idea what's up with the tests?
|
|
How do participants end up with that much of a negative balance? |
rohitpaulk
force-pushed
the
fake-data-subscriptions-and-payments
branch
2 times, most recently
from
664db12 to
ee0db71
Compare
|
Hmm, still can't figure out the negative balances. |
|
Looks like the issue is present on master too. This PR is definitely an improvement over what's in master, so I'd merge it in once we can figure out why the tests aren't passing. (#3596 (comment)) |
Weird. This PR doesn't even modify |
|
Is it something to do with build caching at Travis? I've restarted the build ... |
|
It's odd that we get |
|
(Restarted build failed, ftr.) |
|
I've figured out the negative balance issue. This is down to participants corresponding to week_payments not having ctime < the end_date for the processing week. These payment values therefore don't get processed and thus cancelled out through exchanges. Happens because participant ctime is also random. Believe this situation would only exist in the dev environment. Removing the ctime < end_date filter for week_participants (i.e. using participants collection as such) resolves the negative balances - except for one bit. The fee value from exchanges still remains. This is because this value has nothing in payments to cancel it out. Not sure how to handle this. Please note the above is solely about payments, however. Residual balances will also be a problem as long as transfers remain, as now, because these are still random values. I suppressed transfers while figuring out the above. |
rorepo
force-pushed
the
fake-data-subscriptions-and-payments
branch
from
f1a009c to
5913628
Compare
|
What's up with this PR, @rorepo @rohitpaulk? What do we need to do to bring this in for a landing? |
|
As far as I remember, the tests were passing on my local. Haven't been able to figure out what's up with Travis |
|
Willing to pick up with this again, @rorepo? It's been hanging open for a while. I've restarted the latest Travis build in case it was a spurious error (missing |
|
@whit537 Some of the changes here are not necessary since we have changed directions. There as things that we may want to remove and some that we can work with. I am going to take some time going through this and consider if it make sense to use this PR or scrape it and just start from scratch...it will take a little time. P.S. And rebasing this with master is another task by itself. 😦 |
I believe they were renamed to |
|
oh ok...I need to keep that in mind |
|
rebased on master. next step is to see what we keep and what we remove. 😱 |
kaguillera
force-pushed
the
fake-data-subscriptions-and-payments
branch
from
a571f98 to
961c720
Compare
|
Also added |
|
I think that is good now...could someone review this. @rohitpaulk @aandis @whit537 etc. |
|
!m @kaguillera |
Added fake subscriptions and payments. Tests have been correspondingly updated.
Tips and transfers have been left as they are, for removal later once migration is complete.
This is ready for review.
Please note one change in particular that needs to be validated, made for week_tips and week_transfers (and the new week_subscriptions and week_payments):
week_tips = filter(lambda x: date <= x['ctime'] < end_date, tips)
was
week_tips = filter(lambda x: date < x['ctime'] < end_date, tips)
Seemed to me that transactions at min_date were being skipped in processing due to the 'date < x['ctime']' condition. This wasn't causing any issues, because this would correspondingly not have gone into exchanges as well.