It looks like we agree that this depending on import order is not on, so we have no choice but to break behaviour in some cases.
Option 1 (don't allow relative references) removes support for relative references in abstract models for everyone. Option 2 (resolve references relative to the first concrete inheriting class) doesn't remove anybody's existing behaviour, just formalises it and clarifies how it's specified. The most anybody has to do to keep doing what they're doing is add an app label to a reference. Option 3 (always resolve references relative to the abstract model) makes impossible something that is currently possible: resolving relative references in the concrete class's app. I like option 2. Being able to define a "floating" reference to a to-be-implemented model in a different app is a useful feature in abstract models. If we can't agree on that, I'd go with option 1. I don't really see abstract models as belonging to an app in the same way concrete models do, and that's reflected in Django in various ways. They're not recognised as models by the app registry, fields in their concrete subclasses belong to the inheriting class (unlike in concrete inheritance), we have app label placeholders for related names, etc. I see them more as a blueprint or template than a model. Options 1 and 2 both reinforce that distinction, option 3 muddies it a bit. Cheers, Alex On Thursday, February 11, 2016 at 5:29:52 AM UTC+8, charettes wrote: > > I should have mentioned that this behavior is reproducible since at least > Django 1.6 and has not been introduced by Django 1.8. I wouldn't be > surprised > if it has always been working before the fix was introduced. > > Still, as you mentionned the conditions required to achieve this were > really > convoluted before the lazy operations refactor. > > Simon > > Le mercredi 10 février 2016 16:11:43 UTC-5, Shai Berger a écrit : >> >> On Tuesday 09 February 2016 23:33:50 charettes wrote: >> > 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): >> > >> >> The explanation is complex enough, the case where it works edgy enough, >> that >> I'd be content to call this a bug in 1.8. I'm pretty sure the specifics >> of this >> resolution are not documented, and my sense from reading the ticket is >> that if >> you'd try to document the behavior you'll reach the conclusion that it >> probably isn't intentional. >> >> My 2 cents, >> Shai. >> >> > >> > [1] >> https://github.com/django/django/commit/bc7d201bdbaeac14a49f51a9ef292d6 >> > [2] https://code.djangoproject.com/ticket/26186 >> > [3] https://code.djangoproject.com/ticket/26186#comment:8 >> > [4] https://code.djangoproject.com/ticket/24215 >> > -- 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/ac07321f-aa6a-47dc-b0f1-d49ba9b71d1c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
