[Django] #22944: Migrate doesn't like ForeignKey being reassigned to a different app's model
Django
----------------------------+----------------------
Reporter: mozumder@… | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-rc-1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+----------------------
Hi,
Django 1.7 RC1 doesn't like it when I try to migrate an app's models.
I have a couple of models in App "Background". Simplified example:
{{{
class Family(models.Model):
name = models.CharField(
_("name"),
max_length=255,
blank=True,
null=True,
)
order = models.PositiveSmallIntegerField(
_("order"),
default=0,
)
parent = models.ForeignKey(
'self',
blank=True,
null=True,
class ImageLayer(models.Model):
family = models.ForeignKey(
Family,
verbose_name=_("Family Name"),
related_name='background_family_name',
null=True,
blank=True,
)
}}}
I have another separate App, "Styles" with a similar Family model:
{{{
class StyleFamily(models.Model):
name = models.CharField(
_("name"),
max_length=255,
blank=True,
null=True,
)
order = models.PositiveSmallIntegerField(
_("order"),
default=0,
)
parent = models.ForeignKey(
'self',
blank=True,
null=True,
)
}}}
Now, I try to delete my "Family" model from the Background App, and
reassign the family field to 'styles.StyleFamily" as:
{{{
class ImageLayer(models.Model):
family = models.ForeignKey(
'styles.StyleFamily',
verbose_name=_("Family Name"),
related_name='background_family_name',
null=True,
blank=True,
)
}}}
Then I run manage.py makemigration and manage.py migrate
I get the following:
{{{
bobby:engine mozumder$ ./manage.py makemigrations
Migrations for 'background':
0002_auto_20140702_1621.py:
- Remove field parent from family
- Delete model Family
- Alter field family on imagelayer
- Alter field family on stack
bobby:engine mozumder$ ./manage.py migrate
Operations to perform:
Synchronize unmigrated apps: grappelli
Apply all migrations: sessions, styles, background, blocks, borders,
defaults, effects, structure, transform, sites, contenttypes, admin,
typography, content, animation, auth, colors, redirects, layout, text,
articles, categories
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
Applying background.0002_auto_20140702_1621...Traceback (most recent
call last):
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/apps/config.py", line 152, in get_model
return self.models[model_name.lower()]
KeyError: 'family'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/db/migrations/state.py", line 79, in render
model = self.apps.get_model(lookup_model[0], lookup_model[1])
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/apps/registry.py", line 190, in get_model
return self.get_app_config(app_label).get_model(model_name.lower())
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/apps/config.py", line 155, in get_model
"App '%s' doesn't have a '%s' model." % (self.label, model_name))
LookupError: App 'background' doesn't have a 'family' model.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/core/management/__init__.py", line 385, in
execute_from_command_line
utility.execute()
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/core/management/base.py", line 337, in execute
output = self.handle(*args, **options)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/core/management/commands/migrate.py", line 160, in
handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/db/migrations/executor.py", line 62, in migrate
self.apply_migration(migration, fake=fake)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/db/migrations/executor.py", line 96, in
apply_migration
migration.apply(project_state, schema_editor)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/db/migrations/migration.py", line 107, in apply
operation.database_forwards(self.app_label, schema_editor,
project_state, new_state)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/db/migrations/operations/fields.py", line 118, in
database_forwards
from_model = from_state.render().get_model(app_label, self.model_name)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
/site-packages/django/db/migrations/state.py", line 89, in render
model=lookup_model,
ValueError: Lookup failed for model referenced by field
background.ImageLayer.family: background.Family
}}}
It seems it doesn't like it when I reassign the "family" field to a
ForeignKey outside the App. This happens even with empty "Family" and
"styles.Family" models.
I avoid this situation by rebuilding the database from scratch and calling
in fixtures. I think this is probably a bug?
This is with Django 1.7 RC1, Python 3.4.0, and Postgres 9.3.4
Anyways, let me know if there is a workaround... thank you!
-bobby
--
Ticket URL: <https://code.djangoproject.com/ticket/22944>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: mozumder@… | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-rc-1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by anonymous):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Oh I'll add that the initial "Family" model is based on mixins from
another App, engine/globals.py:
{{{
from engine.globals import Named, Ordered, Family, FamilyMember
class Family(Family):
class Meta:
verbose_name_plural = "Families"
}}}
with engine/globals.py having the following:
{{{
class Ordered(models.Model):
order = models.PositiveSmallIntegerField(
_("order"),
default=0,
)
class Meta:
abstract = True
ordering = ['order']
class Named(models.Model):
name = models.CharField(
_("name"),
max_length=255,
blank=True,
null=True,
)
def get_name(self): # Python 3: def __str__(self):
return self.name
def __str__(self): # Python 3: def __str__(self):
return "%s" % self.name
class Meta:
abstract = True
class Family(Named, Ordered):
parent = models.ForeignKey(
'self',
blank=True,
null=True,
)
def get_family(self): # Python 3: def __str__(self):
return self.name
def __str__(self): # Python 3: def __str__(self):
if self.parent:
return "%s (%s)" % (self.name, self.parent.name)
else:
return "%s" % self.name
class Meta:
abstract = True
verbose_name_plural = "Families"
class FamilyMember():
def get_family(self): # Python 3: def __str__(self):
return self.family.get_name()
}}}
Not sure if that affects expected behavior...
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:1>
Django
Reporter: mozumder@… | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-rc-1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
Possibly related/duplicate of #22970.
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:2>
Django
Reporter: mozumder@… | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-rc-1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
I have same problem after commit fe5f29e.
It's not related/duplicate of #22970. :(
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:3>
Django
Reporter: mozumder@… | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-rc-1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by shawn.holyoak@…):
I get the same error on 1.7 RC1. I have two apps, both created pre 1.7,
that had no reference to each other. I made migrations for both, and
applied them (Faked correctly). Then I changed the foreign keys in one app
to point to a model in the second app. I get ValueError: Lookup failed for
model referenced by field tracking.PropertyDescription.verified_by:
employees.Employee. I asked a question on the Google group
[https://groups.google.com/forum/#!topic/django-users/9wgCcuSdVmo], which
specifies a bit more detail, but today I created a brand new project to
test this and received the exact same error. I don't know if it's exactly
the same issue, but it happens consistently. I'll be glad to file another
bug if it isn't the same issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:4>
Django
Reporter: mozumder@… | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:5>
Django
Reporter: mozumder@… | Owner: andrewgodwin
Type: Bug | Status: assigned
Component: Migrations | Version: 1.7-rc-1
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by andrewgodwin):
* owner: nobody => andrewgodwin
* status: new => assigned
Comment:
Looks like the cause of this is the autodetector not knowing that foreign
key alters should come before deletion of the model they used to point to.
Since there are no steps to reproduce or example project, I'll fix that
bug and mark this as closed and then if it still persists it can be
reopened.
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:6>
Django
Reporter: mozumder@… | Owner: andrewgodwin
Component: Migrations | Version: 1.7-rc-1
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Andrew Godwin <andrew@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"805774df1f2ec9552f1d9c826f5ca9276684da11"]:
{{{
#!CommitTicketReference repository=""
revision="805774df1f2ec9552f1d9c826f5ca9276684da11"
Fixed #22944: Bad dependency on FK alteration in autodetector
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:7>
Django
Reporter: mozumder@… | Owner: andrewgodwin
Type: Bug | Status: closed
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Andrew Godwin <andrew@…>):
In [changeset:"7e708a2536d4828d06f7aa4002fbd5cfc20bef16"]:
{{{
#!CommitTicketReference repository=""
revision="7e708a2536d4828d06f7aa4002fbd5cfc20bef16"
[1.7.x] Fixed #22944: Bad dependency on FK alteration in autodetector
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:8>
Django
Reporter: mozumder@… | Owner: andrewgodwin
Type: Bug | Status: closed
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by nikita@…):
I get the same error on 1.7 RC2. Here is my code
https://github.com/shultais/bug22944
Error with FK and M2M too.
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:9>
Django
Reporter: mozumder@… | Owner: andrewgodwin
Component: Migrations | Version: 1.7-rc-2
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by andrewgodwin):
* status: closed => new
* version: 1.7-rc-1 => 1.7-rc-2
* resolution: fixed =>
Comment:
Confirmed. Reopening.
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:10>
Django
Reporter: mozumder@… | Owner: andrewgodwin
Component: Migrations | Version: 1.7-rc-2
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by andrewgodwin):
* status: new => closed
* resolution: => fixed
Comment:
OK, this bug is different to the one originally reported here, and looks
to be the same as #23100. Re-closing this and transferring to that one as
the main tracking bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/22944#comment:11>