[Django] #25858: Deriving from abstract model with foreign key to model in same app broken on Django 1.9
Django
on Django 1.9
----------------------------------------------+--------------------
Reporter: kaedroho | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
As of Django 1.9, it is no longer possible to derive a new model from
abstract model in another app if that abstract model has a local foreign
key to a model in the same app.
See example project here: https://github.com/kaedroho/djangobugtest
For example, I have two apps: app1 and app2
app1 contains a concrete model and an abstract model. The abstract model
has a foreign key to the concrete one (note the Foreign key is defined as
a string and doesn't include the app label):
{{{
class ConcreteModel(models.Model):
pass
class AbstractModel(models.Model):
foreign_key = models.ForeignKey('ConcreteModel')
class Meta:
abstract = True
}}}
In app2, we have another model that derives from the abstract model in app
1
{{{
class DerivedModel(app1.AbstractModel):
pass
}}}
When running makemigrations, the following system check error occurs:
{{{
app2.DerivedModel.foreign_key: (fields.E300) Field defines a relation with
model 'ConcreteModel', which is either not installed, or is abstract.
}}}
For apps upgrading to Django 1.9 and already have migrations, the
following error occurs when running tests (after the database has been
initialised but before the first test runs. It looks like it's happening
while serialising the database):
{{{
ValueError: Related model u'ConcreteModel' cannot be resolved
}}}
Traceback from an actual site:
https://gist.github.com/kaedroho/01b29332308018abfa29
This issue only occurs when the ForeignKey is defined with a string that
doesn't contain the app label. So referencing the model class directly or
using "app_label.ModelName" works.
--
Ticket URL: <https://code.djangoproject.com/ticket/25858>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
on Django 1.9
Reporter: kaedroho | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Severity: Normal | Resolution:
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 kaedroho):
* cc: kaedroho (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:1>
Django
on Django 1.9
Reporter: kaedroho | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by kaedroho):
git bisect points here:
https://github.com/django/django/commit/9239f1dda7b94f53d21efb8b5e4d056e24f4e906
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:2>
Django
on Django 1.9
Reporter: kaedroho | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* cc: charettes (added)
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
Not sure if the issue can/should be fixed, but we could at least document
the requirement and backwards incompatibility.
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:3>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* status: new => assigned
* owner: nobody => charettes
Comment:
I think we should try fixing this. It can lead to confusing errors if a
second `ConcreteModel` is defined in app2 for example. I'll see if I can
come up with a non-invasive patch.
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:4>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I guess there's a small design decision about whether or not it could
possibly be a useful "feature" to have the option of using the model name
only in the `ForeignKey` to be able to refer to a local model in the app
in which the abstract model is actually used and to require an `app_label`
in the `ForeignKey` otherwise?
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:5>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
Indeed, I've been trying to reach Carl to talk about it but I guess I
should simply write to @developpers.
If we were to consider this change as a feature I guess we should go
through a deprecation period.
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:6>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
Posted to @developpers: https://groups.google.com/d/msg/django-
developers/jRut8aYEet0/IrSiXwK5EgAJ
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:7>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/5964 PR] based on input from
Markus, Shai and Aymeric.
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:8>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:9>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Component: Database layer | Version: 1.9
(models, ORM) |
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Simon Charette <charette.s@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"bc7d201bdbaeac14a49f51a9ef292d6312b4c45e" bc7d201b]:
{{{
#!CommitTicketReference repository=""
revision="bc7d201bdbaeac14a49f51a9ef292d6312b4c45e"
Fixed #25858 -- Bound abstract model application relative relationships.
Thanks to Karl Hobley for the report and Markus, Shai, Aymeric for their
input
and Tim for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:10>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: closed
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Simon Charette <charette.s@…>):
In [changeset:"27ef6403c8b9f332feb1f9fe52053ded0b91da85" 27ef6403]:
{{{
#!CommitTicketReference repository=""
revision="27ef6403c8b9f332feb1f9fe52053ded0b91da85"
[1.9.x] Fixed #25858 -- Bound abstract model application relative
relationships.
Thanks to Karl Hobley for the report and Markus, Shai, Aymeric for their
input
and Tim for the review.
Backport of bc7d201bdbaeac14a49f51a9ef292d6312b4c45e from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:11>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: closed
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
In order to fix #26186 the patch for this ticket is planed to be reverted
in Django 1.9.3.
The suggested approach for the issue reported here is to bound your app
relative reference to an application (`app_label.ConcreteModel` in your
reported case) because what we initially thought as a new behavior
introduced in Django 1.9 has been possible since at least Django 1.2 given
the appropriate setup.
In order to support both use cases it was decided that app relative lazy
relationships should be resolved against their concrete model's
`app_label` and an explicit `app_label` should be added to the lazy
relationship if the abstract model was meant to be used in a foreign
application while maintaining a relationship to a specific application's
model.
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:12>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: closed
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Simon Charette <charette.s@…>):
In [changeset:"0223e213dd690b6b6e0669f836a20efb10998c83" 0223e213]:
{{{
#!CommitTicketReference repository=""
revision="0223e213dd690b6b6e0669f836a20efb10998c83"
Fixed #26186 -- Documented how app relative relationships of abstract
models behave.
This partially reverts commit bc7d201bdbaeac14a49f51a9ef292d6312b4c45e.
Thanks Tim for the review.
Refs #25858.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:13>
Django
on Django 1.9
Reporter: kaedroho | Owner: charettes
Type: Bug | Status: closed
Component: Database layer | Version: 1.9
(models, ORM) |
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Simon Charette <charette.s@…>):
In [changeset:"48cf7516409c668bf11e24e6b7cd8eaea13ae3b8" 48cf7516]:
{{{
#!CommitTicketReference repository=""
revision="48cf7516409c668bf11e24e6b7cd8eaea13ae3b8"
[1.9.x] Fixed #26186 -- Documented how app relative relationships of
abstract models behave.
This partially reverts commit bc7d201bdbaeac14a49f51a9ef292d6312b4c45e.
Thanks Tim for the review.
Refs #25858.
Backport of 0223e213dd690b6b6e0669f836a20efb10998c83 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25858#comment:14>