-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1/2]: Overhaul of donations module #604
Conversation
- Payment table will save the information regarding the payment - Donation table will save information regarding the donation(e.g. campaign, wish etc..)
In future situations, we might need to decrement many vaults at once as well,(e.g. payment refund etc..) - Added some unit tests to cover vaults updates -Did some refactoring on commonly used types, as well as test mocks
As the name of the model is used as a type, the acceptednaming convention is to name that type in singular way
✅ Tests will run for this PR. Once they succeed it can be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all looks great to me and only a few minor comments here&there
) RETURNING id | ||
) | ||
|
||
SELECT * INTO payment_result FROM payment; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
payment_results looks unused, but seems not a problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's used in the statement below, when inserting the id of the inserted payment row, into donations
table.
@@ -23,4 +28,49 @@ describe('VaultService', () => { | |||
it('should be defined', () => { | |||
expect(service).toBeDefined() | |||
}) | |||
|
|||
it('decrementManyVaults should throw an error if one vaults returns negative amount', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great addition!
Fixes TS related errors
…when simulating IRIS transactions
Motivation and context
Currently two major features are queued:
It was discussed among the PM, and dev team, that our current structure is not fit for situations, where funds from one payment can be allocated to more than one campaign.
For this reason a new structure was proposed, which makes the relation between a payment and campaign vaults M:N, with donations table being the "middle-man", connection a payment to campaign vault. Figure below"
To make this happen, the current donations structure, was split into two tables payments and donations, with relation between those tables being 1:N(one payment, can be linked to one or more donations)
Testing
Steps to test
New endpoints
/donations/payments - Get information just for the made payments