-
-
Notifications
You must be signed in to change notification settings - Fork 33.1k
Fixed #23609 -- Changed behavior when dropping a NULL constraint to update rows with NULL to default #3320
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
Buildbot, test this please. |
tests/schema/tests.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.
assertIsNone
f6a28f9
to
7600bb3
Compare
django/db/backends/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.
Why are you setting it to None
here? It looks like it's not used between this line and line #581
.
django/db/backends/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.
we didn't
Patch is looking good, but shouldn't the questioner play a part in this? The same way that adding a NOT NULL field triggers it, see |
I added a commit to integrate the migration questioner. |
Tests failed because of some checkout issue |
buildbot, retest this please. |
django/db/migrations/questioner.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.
Maybe a little too familiar wording? Also a suggestion of what one may want to do would be helpful, for instance: (e.g. deal with existing NULL using a separate RunSQL or RunPython operation)
.
7d06735
to
02bbb7f
Compare
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.
is print_function needed? it doesn't appear in the rest of the code 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.
I guess it's a bit defensive, it helps ensuring that behavior is always identical.
print("hello",)
would give different results in PY2 and PY3 for instance.
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 the right way to support Python 2 and Python 3. See PEP 3105. I mean, I can drop it again, but I don't see the reason for that.
django/db/migrations/questioner.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.
Think the position of the newline should be altered -- above it seems to be so that the line fits in a standard size terminal window -- here the first line is too long -- should break after "non-nullable" 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.
Also message above doesn't have quotes around the model name.
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.
Once (field_name, model_name) expand I doubt it'll fit in 80chars even above.
Good catch on the quote inconsistency.
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 agree on the quotes, but I'm with @loic on the word wrap.
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.
Hm yea, I wonder if we should just remove the newlines then and let the terminal window wrap the lines. It looks funny now to have a newline after the semicolon. Actually would django.utils.text work to automatically insert the newlines?
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.
Yeah, we could use django.utils.text.wrap()
in the questioner, but I'd do that in a separate commit / pull request.
django/db/migrations/questioner.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.
"operation in the new migration file before the AlterField operation" (to give better guidance?)
need newlines in the this message
…olumn into a NOT NULL one due to existing rows Thanks to Simon Charette, Loic Bistuer and Tim Graham for the review.
Ticket: https://code.djangoproject.com/ticket/23609