#23983 closed Bug (fixed)
Cannot Alter order_with_respect_to after there is already data in a table
| Reported by: | James Pulec | Owned by: | Andriy Sokolovskiy |
|---|---|---|---|
| Component: | Migrations | Version: | 1.7 |
| 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
Due to the way that migration operation 'AlterOrderWithRespectTo' is implemented, it will not set a default for the '_order' column it tries to create. Because of this, it is not possible to change 'order_with_respect_to' once there is already data in your database, since the SQL it generates is 'ALTER TABLE "test_app_eggs" ADD COLUMN "_order" integer NOT NULL;'.
Inital models:
from django.db import models
# Create your models here.
class Spam(models.Model):
name = models.CharField(max_length=200)
class Eggs(models.Model):
spam = models.ForeignKey('test_app.Spam')
name = models.CharField(max_length=200)
Then add some data, and change the models to:
from django.db import models
# Create your models here.
class Spam(models.Model):
name = models.CharField(max_length=200)
class Eggs(models.Model):
spam = models.ForeignKey('test_app.Spam')
name = models.CharField(max_length=200)
class Meta:
order_with_respect_to = 'spam'
and then make migrations and try to migrate results in the following traceback:
(test_project)~/test_project/test_project: $ python manage.py migrate
Operations to perform:
Apply all migrations: admin, test_app, contenttypes, auth, sessions
Running migrations:
Applying test_app.0002_auto_20141211_2202...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 160, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 63, in migrate
self.apply_migration(migration, fake=fake)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 97, in apply_migration
migration.apply(project_state, schema_editor)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/migrations/migration.py", line 107, in apply
operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/migrations/operations/models.py", line 328, in database_forwards
field,
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/backends/schema.py", line 390, in add_field
self.execute(sql, params)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/backends/schema.py", line 99, in execute
cursor.execute(sql, params)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/home/james/.virtualenvs/test_project/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.IntegrityError: column "_order" contains null values
Change History (8)
comment:1 by , 11 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 11 years ago
South sets 0 as default value for new created _order column entries, i think in that case it should be the same.
Or, maybe it needed a new questioner? But it seems to will have no profit.
comment:6 by , 11 years ago
I think we should set an initial ordering (https://github.com/django/django/blob/aa5ef0d4fc67a95ac2a5103810d0c87d8c547bac/django/db/models/base.py#L1624-L1633) . Otherwise upcoming saves will start to be ordered, while old data isn't. The ordering of the existing data should be done by the default ordering of the referenced model (model._meta.ordering)
comment:7 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
I'll try to fix that