#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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/010701947b0b9001-851e9b90-577b-4037-ae06-a667feec786c-000000%40eu-central-1.amazonses.com.

Reply via email to