On Fri, Jan 22, 2010 at 10:22 AM, Igor <igor.rubinov...@gmail.com> wrote: > I would not like to rely on fieldname__regex because it's database- > dependent. > I've thought about lists as well, but not sure whether it's a good > idea if it loses the queryset-ness.
If a thing is still a queryset proper, it has to embody SQL that can fetch what you want. If you want database independence (good luck) the query must only use (the commonly correctly implemented subset of) standard SQL. Once you have examined the data in python, the query has already been run. If you look at all of the returned objects in python, they have all arrived in memory, and making a list of them is nearly free. I'm guessing that you want this to remain queryset-like because you want to apply further filtering to it beyond these exclusions. If so, are you sure that you can't reorganize to do these exclusions last? Or do you need to include instances (rows) in you calculation of the exclusion based on rows that will eventually be excluded by the other filters? Another possibility, if you can express your constraints in standard SQL is to use the extra() method of querysets to specify additional WHERE clauses (will be ANDed with other constraints). Again if you can do it with standard SQL, there is always the custom query. There is, however, a lot of manual labor involved in generating instances from the return. This is expected to get much easier, or so I've heard, in 1.2. And, of course, you don't need to generate actual instances if you don't intend to modify and save them, and can pick and choose the fields you want to return (this, too, has it's details to work out). Bill -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
