-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: set non-required fields as nullable #63
Conversation
Coverage reportThe coverage rate went from
Diff Coverage details (click to unfold)src/entities/models/dao.py
src/entities/models/dto.py
src/entities/repos/institutions_repo.py
|
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.
thumbs up
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.
Looks good.
@@ -74,6 +74,22 @@ async def upsert_institution(session: AsyncSession, fi: FinancialInstitutionDto) | |||
session.add(db_fi) | |||
else: | |||
db_fi.name = fi.name | |||
db_fi.tax_id = fi.tax_id |
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.
Don't want to hold up this PR over this, but might be worth checking into SQL Alchemy's built-in upsert functionality.
It'd at least remove the duplicate property setting bits...I think. Of course, there's probably a performance question to consider for this endpoint since it's probably going to be hit a lot at least during initial institution data load. Then again, we'll probably want to support a bulk upload in the long run, so many it's not an issue.
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.
Yeap, this endpoint was originally thought of as a "convenience" endpoint; when we load actual data, it should be outside of using the API; I'll create a ticket on the upsert part, had a glance at the beginning and they were more direct table insertion based rather than the ORM way of doing things; doesn't hurt to see of the ORM upsert is there, and easily implementable, would certainly get rid of a lot of boilerplate.
closes #62