-
Notifications
You must be signed in to change notification settings - Fork 1k
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
More backref_cascade fixes (SQLAlchemy 2.0) #13498
Conversation
Duplication is intetional: this way, after migrating to SA2.0m, we can remove such statements one at a time.
No need to fix in the model, as this only reflects the way model objects are handled in the test module.
Note: Both user and custos_authnz_token are explicitly added to the session; however, user is in the session already, so that may be reducndant. This needs to be checked after migrating to 2.0.
I'm very nervous about this, we have no way of knowing that we didn't pull in something we didn't want to persist with this approach. |
If it happens in the test, I fix it in the test; but if it happens in the model, I modify the model. By "it" I mean a situation like this: assert inspect(foo).session is None
assert inspect(some_bar).session
foo.bar = some_bar
assert inspect(foo).session is inspect(some_bar).session In other words, SQLAlchemy already adds foo to the session - the warning simply tells us that this is happening at that spot and will stop happening with 2.0 (or the future flag). |
Didn't have to rerun integration tests - failure was unrelated. |
@mvdbeek thank you for merging! Just as a reassurance - I've been weighing exactly the same concerns you mentioned; I make such session-related edits after carefully verifying - as much as reasonably possible - that unexpected things are not going to happen. That said, it is not impossible that a test triggers this behavior because the associated object (constructed in the test code) has a session, whereas at runtime it would not have a session. In that case, we would be indeed adding an object to the session prematurely. However, I think, this scenario is not very likely, whereas the scenario we are addressing here is very likely. In any case, the statements are explicit (and finite - there are only so many of them), which provides a direction for debugging, if need be. Thanks again for reviewing this! |
Ref: #12541 (follow-up on #13458)
This includes all backref_cascade fixes triggered by python unit tests.
How to test the changes?
(Select all options that apply)
License