Opened 8 years ago

Last modified 2 years ago

#28000 closed Cleanup/optimization

Migration forces "DROP DEFAULT" SQL — at Version 1

Reported by: Matteo Pietro Russo Owned by: nobody
Component: Migrations Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Matteo Pietro Russo)

If i consider to modify a column (ChaField) to add a default value as follow:

from django.db import models

class PersonModel(models.Model):
    nickname = models.CharField(default="noname", max_length=100, null=False)

makemigration insists on creating a new migration for this change. However, the migration on MYSQL shows:

BEGIN;
ALTER TABLE "core_personmodel" ALTER "nickname" SET DEFAULT 'noname';
ALTER TABLE "core_personmodel" ALTER "nickname" DROP DEFAULT;
COMMIT;

I think there is a mistake at line 735 in django/db/backends/base/schema.py

        # Drop the default if we need to
        # (Django usually does not use in-database defaults)
        if needs_database_default:
            sql = self.sql_alter_column % {
                "table": self.quote_name(model._meta.db_table),
                "changes": self.sql_alter_column_no_default % {
                    "column": self.quote_name(new_field.column),
                }
            }
            self.execute(sql)

If I "needs_database_default", why we need to drop default (sql_alter_column_no_default)? I read we use it to prevent extraneous DROP DEFAULT statements (an example is LONGTEXT in MySQL) because if database is able to use default we need to avoid to drop it.

Change History (1)

comment:1 by Matteo Pietro Russo, 8 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.
Back to Top