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. 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. *Tobias McNulty*Chief Executive Officer tob...@caktusgroup.com www.caktusgroup.com -- 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/CAMGFDKQTEO%3DZug%3DCbrugX-mYV2wFAa3t7YHEKSUgtkAsJ_yX9Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.