Hi Alex, thanks for chiming in. Just to make sure I understand your second proposed option; I'm having a hard time understanding how it's different from simply reverting the fix for #25858[1].
Are you suggesting that the abstract model's foreign key be resolved or the copy.copy()'ied field attached to the concrete model be. If the former is ever resolved it will breaks the behavior reported in #26186 as the second concrete model subclassing the abstract one will point to the first application referred model. If only the latter are resolved this will be equivalent to reverting the fix for #25858[1]. Am I missing something? Simon [1] https://code.djangoproject.com/ticket/25858 [2] https://code.djangoproject.com/ticket/26186 Le mercredi 10 février 2016 22:27:40 UTC-5, Alex Hill a écrit : > > 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 [email protected]. To post to this group, send email to [email protected]. 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/b4d36464-1b16-441f-a45e-f8c5ec31f9ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
