[Django] #28884: Regression in Django 2.0: RenameField throws AttributeError
Django
-----------------------------------------------+------------------------
Reporter: Emanuele Di Giacomo | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 2.0
Severity: Release blocker | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------------+------------------------
Original issue: https://groups.google.com/forum/#!topic/django-
users/O7s658gIHTE
With Django 2.0, a `RenameField` on a model which has a reverse many to
many relationship raises an exception: `AttributeError: 'ManyToManyRel'
object has no attribute 'field_name'`.
This is a regression in Django 2.0: the same migration with Django 1.11
terminates successfully
Below the code and the commands to reproduce the problem:
{{{
# myapp/models.py
from django.db import models
class ModelA(models.Model):
new_name = models.IntegerField()
class ModelB(models.Model):
model_as = models.ManyToManyField('ModelA')
# myapp/migrations/0001_initial.py
from django.db import migrations, models
class Migration(migrations.Migration):
initial = True
dependencies = [
]
operations = [
migrations.CreateModel(
name='ModelA',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
('old_name', models.IntegerField()),
],
),
migrations.CreateModel(
name='ModelB',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
('model_as', models.ManyToManyField(to='myapp.ModelA')),
],
),
]
# myapp/migrations/0002_auto_20171204_1012.py
from django.db import migrations
class Migration(migrations.Migration):
dependencies = [
('myapp', '0001_initial'),
]
operations = [
migrations.RenameField(
model_name='modela',
old_name='old_name',
new_name='new_name',
),
]
$ ./manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, myapp, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying myapp.0001_initial... OK
Applying myapp.0002_auto_20171204_1012...Traceback (most recent call
last):
File "./manage.py", line 15, in <module>
execute_from_command_line(sys.argv)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/core/management/__init__.py", line 371, in
execute_from_command_line
utility.execute()
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/core/management/__init__.py", line 365, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/core/management/base.py", line 335, in execute
output = self.handle(*args, **options)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/core/management/commands/migrate.py", line 200, in handle
fake_initial=fake_initial,
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/migrations/executor.py", line 117, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
fake_initial=fake_initial)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/migrations/executor.py", line 147, in
_migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake,
fake_initial=fake_initial)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/migrations/executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/migrations/migration.py", line 122, in apply
operation.database_forwards(self.app_label, schema_editor, old_state,
project_state)
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/migrations/operations/fields.py", line 304, in
database_forwards
to_model._meta.get_field(self.new_name),
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/backends/sqlite3/schema.py", line 81, in alter_field
any(r.field_name == old_field.name for r in
model._meta.related_objects)):
File "/home/edg/src/example/env/lib/python3.6/site-
packages/django/db/backends/sqlite3/schema.py", line 81, in <genexpr>
any(r.field_name == old_field.name for r in
model._meta.related_objects)):
AttributeError: 'ManyToManyRel' object has no attribute 'field_name'
$ pip freeze
Django==2.0
pytz==2017.3
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28884>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Emanuele Di Giacomo | Owner: Simon
| Charette
Type: Bug | Status: assigned
Component: Migrations | Version: 2.0
Severity: Release blocker | Resolution:
Keywords: | 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):
* status: new => assigned
* owner: nobody => Simon Charette
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28884#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Emanuele Di Giacomo | Owner: Simon
| Charette
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--
Ticket URL: <https://code.djangoproject.com/ticket/28884#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Emanuele Di Giacomo | Owner: Simon
| Charette
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Simon Charette):
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/9421
--
Ticket URL: <https://code.djangoproject.com/ticket/28884#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Emanuele Di Giacomo | Owner: Simon
| Charette
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: sqlite3 sqlite | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Ramiro Morales):
* keywords: => sqlite3 sqlite
--
Ticket URL: <https://code.djangoproject.com/ticket/28884#comment:4>
Django
(sqlite3)
-------------------------------------+-------------------------------------
Reporter: Emanuele Di Giacomo | Owner: Simon
| Charette
Component: Migrations | Version: 2.0
Severity: Release blocker | Resolution: fixed
Keywords: sqlite3 sqlite | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"9f7772e098439f9edea3d25ab127539fc514eeb2" 9f7772e]:
{{{
#!CommitTicketReference repository=""
revision="9f7772e098439f9edea3d25ab127539fc514eeb2"
Fixed #28884 -- Fixed crash on SQLite when renaming a field in a model
referenced by a ManyToManyField.
Introspected database constraints instead of relying on
_meta.related_objects
to determine whether or not a table or a column is referenced on rename
operations.
This has the side effect of ignoring both db_constraint=False and virtual
fields such as GenericRelation which aren't backend by database level
constraints and thus shouldn't prevent the rename operations from being
performed in a transaction.
Regression in 095c1aaa898bed40568009db836aa8434f1b983d.
Thanks Tim for the additional tests and edits, and Mariusz for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28884#comment:5>
Django
(sqlite3)
-------------------------------------+-------------------------------------
Reporter: Emanuele Di Giacomo | Owner: Simon
| Charette
Type: Bug | Status: closed
Severity: Release blocker | Resolution: fixed
Keywords: sqlite3 sqlite | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"b40a1d774d6e7dc0a3663a69c3a8a9b8793d31ff" b40a1d7]:
{{{
#!CommitTicketReference repository=""
revision="b40a1d774d6e7dc0a3663a69c3a8a9b8793d31ff"
[2.0.x] Fixed #28884 -- Fixed crash on SQLite when renaming a field in a
model referenced by a ManyToManyField.
Introspected database constraints instead of relying on
_meta.related_objects
to determine whether or not a table or a column is referenced on rename
operations.
This has the side effect of ignoring both db_constraint=False and virtual
fields such as GenericRelation which aren't backend by database level
constraints and thus shouldn't prevent the rename operations from being
performed in a transaction.
Regression in 095c1aaa898bed40568009db836aa8434f1b983d.
Thanks Tim for the additional tests and edits, and Mariusz for the review.
Backport of 9f7772e098439f9edea3d25ab127539fc514eeb2 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28884#comment:6>