> 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.
It wouldn't do completely different things, the cache would simply be kept as long as possible. If, for example, filter() and exclude() support maintaining the cache but order_by doesn't, qs.filter().order_by() still needs to work, so all the SQL modification still has to happen. filter() or exclude() would only do "completely different" things in the same sense that iterating through a QS does completely different things based on whether it has been filled or not. > 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. Hmm, this is a deal breaker. I wouldn't mind doing things a little differently from the Usual Python Way(tm) in order to match all the databases, but if different DBs treat something as simple as "WHERE fieldname='value'" differently then a generic implementation isn't possible - it'll have to be up to application code (as you all have said). Here's as far as I got on a patch to queryset-refactor: http://dpaste.com/hold/45560/ The general idea was that it doesn't have to handle every possible filter() or exclude(), it just has to fail (set the new QS's cache to None) quickly. Thanks for scaring me off of a bad idea. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
