On Monday 21 August 2017 18:44:35 Tobias McNulty wrote: > On Sat, Aug 19, 2017 at 1:10 PM, Luke Plant <l.plant...@cantab.net> wrote: > > This could work something like the way that ForeignKey `on_delete` works > > - you have options that are enumerated as constants, but in reality they > > are classes that embody the strategy to be used. We could have something > > similar - `on_missing_relation=FETCH | WARN | ERROR | IGNORE ... ` > > I like this a lot. It (1) caters (I think) to many if not all of the > behavior preferences expressed in this thread, (2) mimics an existing API > we support, (3) allows projects to gradually add/try the feature, and (4) > permits but does not require a deprecation path for changing the default > behavior in the future. I'm assuming `FETCH` represents the current > behavior and not auto-detection of a missing relation and modification of > the associated QuerySet. >
I agree that the idea sounds nice, with one exception: It seems like this would make sense, mostly, at the foreign-key-definition level, which means the feature is applied at model scope -- altough it isn't quite clear. However, the main argument so far was exactly about the right scope to use, with four different suggestions as far as I could see (queryset, model, context-manager and a global setting), each with its own pros and cons. So, it feels a little like going off the main thread of discussion. > One alternative thought: Could we define two `ForeignKey` options (again > using the `on_delete` analogy) which support adding the relation to > select_related()/prefetch_related() all the time (e.g., > `ForeignKey(prefetch_related=ALWAYS | MANUALLY | WARN | ERROR)` and/or > `ForeignKey(select_related=ALWAYS | MANUALLY | WARN | ERROR)`, where > MANUALLY represents the current behavior)? One could then use `.only()` or > `.values*()` to avoid fetching the related model, if needed. > This is truly, clearly off-topic here; I just want to point out that the effect can already be achieved by overriding the model's default manager's get_queryset(). The idea might have merits in terms of maintainability and readability, but I'd much rather it be discussed separately. Shai
