-
-
Notifications
You must be signed in to change notification settings - Fork 33k
Fixed #14204 -- Added support for SQLite foreign key constraints. #8678
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
Conversation
2144c6c
to
2013763
Compare
There are still some test failures with |
django/db/backends/sqlite3/schema.py
Outdated
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 wonder how this will play with existing SQLite tables that don't have DEFERRABLE INITIALLY DEFERRED
constraints. At this point I think the best course of action would be to mention it in the release notes.
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'm not sure exactly what the ramifications might be. Anything specific to mention besides what I wrote so far?
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 think the text you added is appropriate. Makes me wonder if we would like to document how to migrate existing foreign keys to DEFERRABLE INITIALLY DEFERRED
(which will be a bit complicated as it will require a table rebuild since SQLite doesn't support ALTER TABLE
) or suggest PRAGMA defer_foreign_keys = ON
should be issued on connection creation when entering a transaction for SQLite databases created with Django < 2.0.
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.
Related to what charettes asked, but asked in a slightly different way:
Assumption: basic migrations will handle the table rebuild, like existing sqlite schema changes.
Question: if PRAGMA foreign_keys is going to be default on in django 2, how will the user "opt in" their old tables to a migration, without there being a difference in their model params?
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.
It's probably feasible to create a script or management command or similar to rebuild tables. I wasn't sure if it's needed; i.e. what circumstances will create a problem with non-upgraded tables? The problems in the test suite related to that seemed to be with flush
which doesn't like a huge concern (if someone wants to do that, just delete the tables instead).
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.
Something along these lines would break on tables that haven't been rebuilt and still have IMMEDIATE
foreign key constraints:
with transaction.atomic():
# The following line will immediately fail now that foreign key
# constraints are enforced and were created as IMMEDIATE
# instead of INITIALLY DEFERRED.
Book.objects.create(author_id=1)
Author.objects.create(id=1)
We might want to mention that constraints used to be built as DEFERRABLE IMMEDIATE
in the Foreign keys are now created with DEFERRABLE INITIALLY DEFERRED
section and might require a rebuild to allow the above pattern to be used.
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, I incorporate this into the release notes.
4c7fd23
to
bda157d
Compare
3ff9e52
to
8524825
Compare
Thanks Tim Graham for contributing to the patch and Simon Charette for advice and review.
https://code.djangoproject.com/ticket/14204
Updated from claudep@15ceb2c