Re: [Django] #35787: CharField migration with preserve_default=False keeps the DB default on Oracle and MySQL

5 views
Skip to first unread message

Django

unread,
Jan 18, 2025, 3:12:28 PMJan 18
to django-...@googlegroups.com
#35787: CharField migration with preserve_default=False keeps the DB default on
Oracle and MySQL
------------------------------+------------------------------------
Reporter: Václav Řehák | Owner: (none)
Type: Bug | Status: new
Component: Migrations | Version: 5.1
Severity: Normal | Resolution:
Keywords: Oracle | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by Chris M):

I have been able to reproduce this behavior only on Oracle.

Using Sarah's original [https://github.com/django/django/pull/18632 PR] as
a guide, I made a slightly more complete
[https://github.com/django/django/compare/main...camuthig:django:35787
-reproduce-preserve-default-bug test] .

This test passes for Postgres, MySQL, and Sqlite. Oracle is the outlier
for two reasons.

First, it doesn't actually set the column to `NOT NULL` ever. That is
because of the `interprets_empty_strings_as_nulls` property on the
[https://github.com/django/django/blob/9fa4d07ce0729850661a31a6b37c6b48f13d2266/django/db/backends/base/schema.py#L1309-L1312
Oracle backend] . This gets ignored, and so a `NOT NULL` statement is
never generated.

The second issue is not dropping the default, which comes down to the
`sql_alter_column_no_default` set on the
[https://github.com/django/django/blob/978aae4334fa71ba78a3e94408f0f3aebde8d07c/django/db/backends/oracle/schema.py#L19
Oracle backend]. Instead of creating a `DROP DEFAULT` statement, this sets
the default to `NULL` explicitly.

I'm not very familiar with the nuances of
[https://docs.djangoproject.com/en/5.1/ref/databases/#null-and-empty-
strings empty and null values] in Oracle (I just finally got the DB
running locally today), so I can't really say what the correct behavior
here is from Django's perspective.
--
Ticket URL: <https://code.djangoproject.com/ticket/35787#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Reply all
Reply to author
Forward
0 new messages