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