To me, "sane default" means django should not silently alter the query to provide a LIMIT when it is not asked for.
I have also run into situations where doing a .count() or iterating a full table has broken the application, or put too much pressure on the database. Specifically with django bindings to javascript datatables. But I still wouldn't want artificial limiting on such queries. What *may* be useful, is to be able to apply queryset methods onto an already sliced queryset. That would allow users to implement queryset/manager methods that provide pre-sliced querysets to the rest of the code. The problem would be, what should happen in this case? Model.objects.all()[0:10].filter(field=True) Should the filter be logically/internally moved to before the limit? Or should the filter be applied to the result of the limit in an outer query? Traditionally, django applies mutations in succession, but this wouldn't be very useful the for the majority of operations that would occur "after" the slicing. We *could* say all slicing is "saved" and applied at the end, but we'd definitely run into issues with users reporting that filtering isn't working as they expect - after the slice. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bef66ad3-c886-4106-8336-a2db13c340cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
