-
Notifications
You must be signed in to change notification settings - Fork 0
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
Unsubscribe: Tables altered and new functions added #53
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.
You're headed in the right direction! Left some small suggestions, but the main thing to work on is creating a database migration for your schema changes
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.
Agree with karl here. If you need help with Alembic just let one of us know -- it's not hard to do by example, but finding the examples and testing can be a bear sometimes.
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.
lgtm, but a suggestion for improvement is included.
|
||
|
||
def upgrade() -> None: | ||
op.add_column("accounts", sa.Column("is_deleted", sa.Boolean, nullable=True)) |
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.
Do we want nullable here? I recognize that you need to make it nullable to add it, but do we want the "final form" of this column to be nullable, or do we want it default-false? What's the difference between is_deleted = null
and is_deleted=False
?
(To do this if memory serves you do an add column that's nullable, update all rows to false, then modify to be non-null)
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.
I had the same approach as well, but went the other way. I shall make the changes
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.
That's not the wrong thing to do, but I suggested skipping it because of a defaults-related hassle:
SQLAlchemy treats non-nullable fields with database-level defaults as required, even though omitting them should theoretically be allowed. If this PR makes the new field non-nullable, it will also need to update the repository code to make sure that field is set whenever we store accounts.
""" | ||
from typing import Sequence, Union | ||
|
||
from alembic import op |
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.
we can probably get this fixed when we want to merge. Manual fixing these isn't too hard, but I think pre-commit run --all-files
or something similar should also fix the problem.
@aisa6148 I think this just needs a few unused imports to be removed from the database migrations in order to pass the CI checks. Otherwise this looks ready to merge? |
@karlhigley All checks have passed for this one (although the error sent over slack persists). Apart from that this branch is updated with main and is ready to merge! |
(Need to test after merging main)
Unsubscribe from emails