I think there's a lot right with your suggestions here Shai. It delivers better default behaviour for new projects, does not affect existing deployments, and seems pretty easy to enable/disable selectively at any level of the stack.
My only concern would be libraries leaning on this behaviour by enabling it locally and users being unable to change it. That's only a small concern though, and wouldn't prevent me from recommending the proposal. On Thursday, 17 August 2017 09:34:03 UTC+10, Shai Berger wrote: > > First of all, I think making the auto-prefetch feature available in some > form > is a great idea. As an opt-in, I would have made use of it on several > occasions, and cut days of optimization work to minutes. It's true that > this > wouldn't achieve the best possible optimization in many cases, but it > would be > close enough, for a small fraction of the effort. > > But of the choices that have been suggested here, I find none quite > satisfactory. I agree, basically, with almost all of the objections raised > on > all sides. And I think I have a better suggestion. > > Rather than a setting (global and essentially constant) or all-local > opt-ins, > suppose the feature was controlled -- for all querysets -- by a context > manager. > > So, rather than > > > "qs.prefetch_related(auto=True)", or "with qs.auto_prefetch():", > > suppose we had > > with QuerySet.auto_prefetch(active=True): > > and under that, all querysets would auto-prefetch. Then: > > - We could put that in a middleware; using that middleware would then, > effectively, be a global opt in. We could add the middleware -- perhaps > commented-out -- to the new project template, for beginner's sake. Call it > PerformanceTrainingWheelsMiddleware, to make people aware that it's > something > they should grow out of, but make it easily accessible. > > - We could easily build a decorator for views > > - We could have local opt-out, at the correct level -- not the objects, > but > the control flow. > > For this to work, the flag controlling the feature would need to be > thread- > local and managed as a stack. But these aren't problems. > > If (as likely) this suggestion still does not generate a concensus, I > would > prefer that we follow the path Anssi suggested -- > > > Note that it should be possible to implement this fully as 3rd party > > project if we add an easy way to customise how related object fetching > is > > done. I'm not sure if we can add an easy way for that. > > Except I don't think "easy" is a requirement here. If we can add a > sensible > way, that would be enough -- I don't expect many Django users to develop > implementations of the feature, only to use them. > > My 2 cents, > Shai. > -- 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/bf3e22af-9a41-4106-b986-fc136d54c4c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
