Hi everyone,
The chosen fix[1] unfortunately introduced a new regression[2].
It looks like the behavior described in the previous ticket was possible
with
Django 1.8 under certain circumstances[3] where the abstract models defined
in a foreign application were derived as concrete models in another
applications
before the abstract models relations are resolved (if they are ever
resolved):
# abstract_app/models.py
class AbstractReferent(models.Model):
refered = models.ForeignKey('Refered')
class Meta:
abstract = True
# app1/models.py
from abstract_app.models import Referent
class Refered(models.Model):
pass
class Referent(AbstractReferent):
pass
Before Django 1.9.2 `Referent.refered` resolved to `Refered` but since the
fix
is applied it attempts to resolve to `abstract_app.Refered` which never
resolves
to any model and results in a check failure.
In the light of this new report I think we should revert the fix as it makes
this "blue print" feature of abstract models unusable. The only thing Django
1.9's refactor of lazy operations[4] changed was to make this feature less
dependent on import side effects and more reliable.
Instead, I suggest we document how app relative relationships are defined on
abstract models.
Thoughts?
Simon
[1]
https://github.com/django/django/commit/bc7d201bdbaeac14a49f51a9ef292d6312b4c45e
[2] https://code.djangoproject.com/ticket/26186
[3] https://code.djangoproject.com/ticket/26186#comment:8
[4] https://code.djangoproject.com/ticket/24215
Le vendredi 8 janvier 2016 16:16:33 UTC-5, charettes a écrit :
>
> During the refactor of lazy operations[1] abstract models stopped resolving
> their related field model reference by themselves[2][3] in order to prevent
> pending lookup pollution. This was necessary in order to warn the users
> about
> unresolved relationships in a reliable way.
>
> This change introduced a subtle regression[4] when an abstract model with a
> lazy app relative (missing an app_label suffix) relationship is derived as
> a concrete model in another application:
>
> # app1/models.py
>
> class Refered(models.Model):
> pass
>
> class AbstractReferent(models.Model):
> refered = models.ForeignKey('Refered')
>
> class Meta:
> abtract = True
>
> # app2/models.py
>
> from app1.models import AbstractReferent
>
> class Refered(models.Model):
> pass
>
> class Referent(AbstractReferent):
> pass
>
> Now that relationships defined on abstract models are only resolved on
> definition of concrete subclasses the `app2.Referent.refered` points to
> `app2.Refered` when it used to point to `app1.Refered`.
>
> Here are the solutions I had in mind:
>
> 1) Refuse the temptation to guess; raise an exception on `app2.Referent`
> definition about the ambigous relationship and point to resolution options.
>
> 2) As abstract models should really just be considered "placeholders for
> fields"
> consider this new behavior the correct one. This could be considered a new
> feature and a deprecation path would have to be thought of.
>
> 3) Revert to the previous behavior by converting app relative lazy
> relationships
> to the "app_label.Model" form on `RelatedField.contribute_to_class`.
>
> I'd favor the first option over the others because I feel like this is
> really
> an edge case where both behaviors have merit (and a bad pratice i'd like to
> prevent) but the third one is definitely the safest option.
>
> Thanks for your feedback,
> Simon
>
> [1] https://code.djangoproject.com/ticket/24215
> [2]
> https://groups.google.com/d/msg/django-developers/U5pdY-WVTes/lqfv9cm9bPAJ
> [3] https://github.com/django/django/pull/4115
> [4] https://code.djangoproject.com/ticket/25858
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3e766894-44fd-4180-9cdf-f3ee55a9a4ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
