Travis Parker wrote: > I was just recently optimizing database usage in a django app and > found myself managing these things myself (sorted(qs) instead of > qs.order_by(), filter(filterer, qs) instead of qs.filter()) because I > didn't want the database to get hit again when modifying already-used > querysets.
I'd be very surprised if .filter or .order_by would do completely different things based on whether a queryset is already filled or not. Currently queryset constructing methods are not completely opaque abstractions of "filtering" and "ordering", and it's good. I think simplicity here wins: I just want to always see in code if I'm constructing a new query or doing things in Python. The second reason for not doing this is that ordering and filtering in database can work differently than "equivalent" operation in Python. For example ordering is greatly depends on db collation. And filtering in MySQL is not strict by default in many setups. Did you know that "where name = 'е'" and "where name = 'ё'" can fetch you the same rows? AFAIK it treats letters with accents and umlauts as equivalent to those without. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
