Re: Lazy operations refactor regression with abstract models #25858

Hi everyone, I submited a PR[1] that partially reverts the initial fix and document how app relative lazy relationships behave when defined on abstract models subclassed as concrete models in foreign applications. Reviews welcome! Simon [1] https://github.com/django/django/pull/6178 Le

Re: Lazy operations refactor regression with abstract models #25858

Hi Simon, Nope, you're not missing anything. I agree with reverting the fix in #25858 and going with approach #2 as outlined in your initial post. Sorry that wasn't clear - I meant to address my response to the thread as a whole, in light of that fix being found to cause another regression.

Re: Lazy operations refactor regression with abstract models #25858

Would love seeing Option 2. I've been relying on this pattern since as far back as django 1.2 on several projects. https://github.com/skyjur/django-ticketing/blob/master/ticket_26186_2/tox.ini https://github.com/skyjur/django-ticketing/blob/master/ticket_26186_2/test-result.txt On Thursday,

Re: Lazy operations refactor regression with abstract models #25858

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

Re: Lazy operations refactor regression with abstract models #25858

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

Re: Lazy operations refactor regression with abstract models #25858

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

Re: Lazy operations refactor regression with abstract models #25858

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

Re: Lazy operations refactor regression with abstract models #25858

Thanks for your input everyone. You convinced me we should with the third option[1] for now. Markus, nothing prevent us from changing this behavior in the future if there's a need for it but since this is a regression and we don't have a clear backward compatible upgrade path defined we should

Re: Lazy operations refactor regression with abstract models #25858

Hello, On 9 janv. 2016, at 19:51, Shai Berger wrote: > So, I say, go for option 3. A field defined in a model in app1 takes app- > relative references in app1. I agree. We’re discussing an unintended regression. The discussion shows possible improvements in this area but

Re: Lazy operations refactor regression with abstract models #25858

On Saturday 09 January 2016 00:15:32 Markus Holtermann wrote: > That's a nice one, Simon. > Yep. [Simon said: 1: error out, 2: take model from child's app; 3: take model from abstract parent's app] > tl;dr: I favor 2; am OK with 1 but against 3. > But here I no longer agree. > I was

Re: Lazy operations refactor regression with abstract models #25858

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

Lazy operations refactor regression with abstract models #25858

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