Hi Alex, Just replying to your other objections, now I've had some time to think about them:
On 27/09/11 03:23, Alex Gaynor wrote: > I'm not a fan of this, for a few reasons, firstly: because it feels > wrong for a QuerySet to execute multiple queries. This isn't a deal > breaker, just something that struck my conceptually initially. For me, QuerySet is at a level of abstraction where I don't think it guarantees a single query. We have quite a bit of precedent here I think: - some methods produce new QuerySets that only execute queries when you iterate over them. - some methods execute queries immediately, like get(), exists() and count(), and *some* slicing operations. - of the latter type, some are optimised to *not* to do queries if we can get the answer from the result cache. (This is not even explicitly documented). So I think QuerySet is at a level where it is expected to give you some more intelligent, optimised tools for executing queries. The actual number of queries executed is non-trivial to work out by looking at the code in front of you, but the documentation, combined with analysis of how the QuerySet was built will give you an upper bound. You can also consider select_related() in this light - code as simple as 'map(unicode, queryset)' can do 1 query or N queries, depending on how the QuerySet was constructed. > Finally (for now ;)) it doesn't feel right for something inside core to > have caveats like "only works if you use .all()", there's a very good > technical reason for this, but something about it is irking me the wrong > way. The 'only works if you use all()' bit is nothing other than the normal behaviour of QuerySets - if you evaluate one QuerySet and fill its result cache, those results will not be used by any QuerySets based off the first via filter() etc. I probably worded it badly. In the implementation, I only modified the RelatedManager.all() methods because if you are doing anything else, you will end up with a clone that has an unfilled QuerySet anyway (if I'm thinking correctly), which is presumably what you want if you do that. For me, the most annoying limitation is the 'single depth' thing. I think it is entirely possible to extend this work and fix that, but that can be added later as an enhancement and the single level version is a useful enough optimisation in its own right. Regards, Luke -- "I spilled spot remover on my dog. Now he's gone." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
