Reward point redemption events #2264
Conversation
hansegucker
force-pushed
the
reward-point-redemption-events
branch
2 times, most recently
from
712cd29
to
51df256
Compare
| form.set("form-0-points", 3) | ||
| form.set("form-1-points", 3) |
There was a problem hiding this comment.
Are "0" and "1" here PKs of the corresponding events, or how do we later map this to events? (I feel like this mapping was lost from the previous post-params)
There was a problem hiding this comment.
There is always a corresponding form field like form-0-pk that does the mapping.
evap/rewards/views.py
Outdated
| total_points_available = reward_points_of_user(request.user) | ||
| events = RewardPointRedemptionEvent.objects.filter(redeem_end_date__gte=datetime.now().date()).order_by("date") | ||
|
|
||
| formset = RewardPointRedemptionFormSet( | ||
| request.POST or None, | ||
| initial=[{"event": e, "points": 0, "total_points_available": total_points_available} for e in events], | ||
| user=request.user, | ||
| ) |
There was a problem hiding this comment.
problematic: total_points_available is computed outside of the transaction/locked critical section, formset clean is computed without database locking, and save might run arbitrarily later -- with the possibility that the same points have been redeemed in between.
For this to be safe, we need to ensure that during the update path, all three steps (calculate limit, clean, save) are stored in the transaction while the rows are locked.
hansegucker
force-pushed
the
reward-point-redemption-events
branch
from
51df256
to
9743c64
Compare
Close #2258
Close #1825