Opened 10 years ago

Last modified 20 months ago

#24434 new Bug

Django Custom Field inherits ForeignKey deconstruct() fails

Reported by: greenbender Owned by: nobody
Component: Documentation Version: 1.7
Severity: Normal Keywords: deconstruct, migration
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When creating a custom field that inherits from ForeignKey and sets the to field there are issues with deconstruction.

Simplified example (models.py)

from django.db import models
from django.contrib.auth.models import User


class UserField(models.ForeignKey):

    def __init__(self, *args, **kwargs):
        kwargs['to'] = User
        super(UserField, self).__init__(*args, **kwargs)

    def deconstruct(self):
        name, path, args, kwargs = super(UserField, self).deconstruct()
        del kwargs['to']
        return name, path, args, kwargs


class FooBar(models.Model):
    user = UserField()

When python manage.py makemigrations is run the following exception is raised.

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 338, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/makemigrations.py", line 111, in handle
    convert_apps=app_labels or None,
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/autodetector.py", line 40, in changes
    changes = self._detect_changes(convert_apps, graph)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/autodetector.py", line 139, in _detect_changes
    self.generate_renamed_models()
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/autodetector.py", line 413, in generate_renamed_models
    model_fields_def = self.only_relation_agnostic_fields(model_state.fields)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/autodetector.py", line 79, in only_relation_agnostic_fields
    del deconstruction[2]['to']
KeyError: u'to'

It can be resolved by not removing the 'to' kwarg during deconstruction, however, this obviously leaves the unrequired 'to' kwarg in the constructor, as follows:

from django.db import models, migrations
from django.conf import settings
import bar.models


class Migration(migrations.Migration):

    dependencies = [
        migrations.swappable_dependency(settings.AUTH_USER_MODEL),
    ]

    operations = [
        migrations.CreateModel(
            name='FooBar',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
                ('user', bar.models.UserField(to=settings.AUTH_USER_MODEL)),
            ],
            options={
            },
            bases=(models.Model,),
        ),
    ]

I've tried a few variations on this (such as supplying User as the first arg to the super call), however, the result is much the same or creates additional problems.

The solution proposed at ticket:22263 may solve this problem.

Change History (5)

comment:1 by Tim Graham, 10 years ago

Component: UncategorizedMigrations
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

comment:2 by Markus Holtermann, 10 years ago

Component: MigrationsDocumentation
Needs documentation: set

Reading through the related issues, especially https://github.com/alex/django-taggit/issues/206#issuecomment-37578676, I think this issue is more a problem with lack of documentation.

comment:4 by Nishant Sagar, 4 years ago

Resolution: fixed
Status: newclosed

comment:5 by Carlton Gibson, 4 years ago

Resolution: fixed
Status: closednew

Hi Nishant. Thanks for the input on the ticket. Can you say how/why it's fixed so we know that's OK to close? ("Latest docs say... and ..." — or such.) 🙏

comment:9 by Mariusz Felisiak, 20 months ago

Needs documentation: unset
Note: See TracTickets for help on using tickets.
Back to Top