#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 django-updates+unsubscr...@googlegroups.com.
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