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
Introduce TransferCommitment API #410
Conversation
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.
Please do not be disheartened by the number of remarks. You did a good job getting accustomed to the existing code structure and following house conventions. But there is some work left to do, both in the stylistic and functional departments:
Co-authored-by: Sandro <sandro.jaeckel@sap.com>
Co-authored-by: Sandro <sandro.jaeckel@sap.com>
Co-authored-by: Sandro <sandro.jaeckel@sap.com>
Co-authored-by: Sandro <sandro.jaeckel@sap.com>
Co-authored-by: Sandro <sandro.jaeckel@sap.com>
Documentation: Fix grammatical indistinctness. Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Nounify variable names of SQL queries. Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Token check: Remove error return message. Already handled by token.Require function. Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Rename: splitCommitment function to buildSplitCommitment. Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Commitment test: Update parameter from snake case to camel case. Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Tests: Negative tests now check the body content
Simplify commitment transfer. Utilize ORM. Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Update transfer commitment test with split commitment
Reminder: Check on Monday - Previous OLTP implementation had a bug in the transferred commitment. The ORM implementation now takes this into account and saves the values in the database. A additional test case was added that tests the transfer of a splitted commitment. |
internal/api/commitment.go
Outdated
|
||
// find commitment by transfer_token | ||
var dbCommitment db.ProjectCommitment | ||
err := p.DB.SelectOne(&dbCommitment, getCommitmentWithMatchingTransferTokenQuery, transferToken) |
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.
Should also match on ID, as defense in depth.
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.
The query now respects the commitment ID (read out of the URL)
internal/api/commitment.go
Outdated
|
||
// get target AZ_RESOURCE_ID | ||
var targetResourceID db.ProjectAZResourceID | ||
err = p.DB.QueryRow(findTargetAZResourceIDBySourceIDQuery, targetProject.ID, dbCommitment.AZResourceID).Scan(&targetResourceID) |
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.
This looks like it does not match on service type and resource name. How is the commitment matched to the correct service and resource on the receiving side?
The tests can plausibly work "by accident" because they all use first/capacity
which is the alphabetically first service/resource.
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.
You are absolutely correct. I fixed this with a Common Table Expression that queries the service type, resource name and AZ from the source commitment.
Additionally I changed the tests to use the service "second". In the old implementation this caused the selected resource_az_id to be from the service "first". It now points to the correct service.
Caused: on multipyle services or resources the first entry was selected and not the values the source commitments holds
Fixed: Movement of the transfer token from queryString into the request header. |
Respects the movement of the transfer token as queryString into the header
productionChecklist:
This PR introduces commitment transfers from a source to a target project.
Two API's will be implemented: