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

[Django]

#35787: CharField migration with preserve_default=False keeps the DB default on
Oracle
------------------------------+------------------------------------
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
------------------------------+------------------------------------
Changes (by Simon Charette):

* cc: Simon Charette (added)
* summary:
CharField migration with preserve_default=False keeps the DB default
on Oracle and MySQL
=>
CharField migration with preserve_default=False keeps the DB default
on Oracle

Comment:

Thanks for investigating Chris!

I think this simply cannot be fixed on Oracle as once a column had a
`DEFAULT` assigned to it, which is a pre-requisite for adding a field to a
table with existing rows for example, Oracle doesn't allow you to drop it
[https://docs.oracle.com/cd//B19306_01/server.102/b14200/statements_3001.htm#sthref5162
per their docs]

> If a column has a default value, then you can use the `DEFAULT` clause
to change the default to `NULL`, but you **cannot remove the default value
completely**. That is, if a column has ever had a default value assigned
to it, then the `DATA_DEFAULT` column of the `USER_TAB_COLUMNS` data
dictionary view will always display either a default value or `NULL`.

Given `NULL` is the closest equivalent to ''not provided'' I think we're
taking the best course of action here as for non-textual columns a
`DEFAULT` of `NULL` will be fine as if the column is nullable data will be
allowed to be inserted otherwise it will crash with an integrity error.
This quirk just happens to conflict with the awkward way Oracle deals with
empty strings considering them the same as `NULL` as it basically means
that `DEFAULT ""` and `DEFAULT NULL` are equivalent.

Hope that explains why the issue cannot be reproduced on MySQL and why
this issue should be closed as wont-fix.
--
Ticket URL: <https://code.djangoproject.com/ticket/35787#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.