That's a nice one, Simon.
tl;dr: I favor 2; am OK with 1 but against 3.
I was favoring 1) as well. But then thought that app relative relationships
actually make sense and the current behavior adds a nice new API feature. This
way a 3rd party app can provide an abstract model and require you to implement
2 models: the inheriting and the referred with a specific name.
Furthermore, if you want a specific model to be used, be explicit about it. Use
the full app.Model name. I think we should emphasize that in our docs and
suggest to use the full name at all times.
The problem we'll be running into with 2 would be a sensible migration path. I
can't think of one right now.
Cheers
/Markus
On January 9, 2016 8:16:32 AM GMT+11:00, charettes <charett...@gmail.com> wrote:
>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/333AF605-822B-46BD-BB2B-CF9040692236%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.
