-
Notifications
You must be signed in to change notification settings - Fork 317
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
Upgrade to sqlalchemy>=2 #1788
Upgrade to sqlalchemy>=2 #1788
Conversation
Failures are unrelated. |
nbgrader/api.py
Outdated
from sqlalchemy.orm import (sessionmaker, scoped_session, relationship, | ||
column_property) | ||
column_property, declarative_base) |
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 preferred method for 2.0 is to use the DeclarativeBase
class. This still works, but switching to the class makes a lot of sense in this PR.
see: https://docs.sqlalchemy.org/en/20/orm/mapping_api.html#sqlalchemy.orm.declarative_base
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.
Thank you for letting me know. I don't recall seeing a mention of this in the migration document (maybe I missed it), but I agree that it makes sense to switch. Will fix accordingly.
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.
@shreve @brichet DeclarativeBase
is apparently a sqlalchemy 2.x addition (without being present in 1.4), so I should have bumped up the minimum version.
The previous declarative_base
imported from sqlalchemy.orm
should work with both 1.4 and 2.x.
The difference between them is for type-checkers, which at least right now is not a big deal for nbgrader
. So I think it is worth going back to declarative_base
over DeclarativeBase
. What do you think?
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.
In light of #1796, I'll open a pr to revert the change to DeclarativeBase
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.
Thanks @tuncbkose, that looks good to me.
I don't really know how to be sure everything will work as before, not sure if the current tests cover it.
cc @jhamrick
@@ -46,7 +46,7 @@ dependencies = [ | |||
"python-dateutil>=2.8", | |||
"rapidfuzz>=1.8", | |||
"requests>=2.26", | |||
"sqlalchemy>=1.4,<2", | |||
"sqlalchemy>=1.4,<3", |
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.
Will it still work with sqlalchemy<2
?
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 tests are still passing for me locally with sqlalchemy 1.4.46. That might be helpful to add to the test matrix if we want to continue supporting <2 moving forward.
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.
My understanding is that sqlalchemy==1.4
supports all the big changes for sqlalchemy==2
. Only the future=True
flags might change behavior (like this).
@tuncbkose can you please rebase it to check if all the tests pass ? |
Thanks @tuncbkose |
* Upgrade to sqlalchemy>=2 * Update alembic migration files for sqlalchemy 2
Most of the required changes so far were fairly innocent.
One of the warnings when running on
sqlalchemy<2
was this one about changing cascade_backref behavior. It is still a bit unclear to me what consequences this change might have, but tests were passing onsqlalchemy<2
with usingfuture=True
inSession
andEngine
, and they are passing now.