A final possibility is to enumerate the id's of the objects that you want to
exclude, and then apply them to an unevaluated copy of the queryset
using exclude, e.g.;
q = base_queryset_construction()
excludes = []
for i in q.all():
if shoud_be_excluded(i):
excludes.append(i.id)
q = q.exclude(id__in=excludes}
Or, if you'll be excluding more than you will be including, you can enumerate
those you want to keep and use them with filter instead of exclude.
On Fri, Jan 22, 2010 at 12:39 PM, Igor <igor.rubinov...@gmail.com> wrote:
> Bill,
>
> You're correct in all your guesses - I want to be able to chain more
> filtering to the query since I'm not sure what and how might use it
> later. Even in the current situation it's much better from design
> standpoint to chain a .distinct() on the set AFTER the exclusion of
> the values I don't like.
>
> I'm not (yet :)) an expert in Django as it's easy to guess, but in my
> understanding even after I've accessed the elements (i.e. SQL has been
> executed) filterng/sorting etc. should be working.
>
> The solution I've implemented for now is instead of creating a list,
> I've created an empty QuerySet and am joining every element I DO want
> to that set. The last line is the join, and my concern is that it's
> not too efficient. I know those result sets are not going to be more
> than 20 elements or even less so the inefficiency is probably
> negligible, but I would still be happy to find a way that would be
> efficient for any set size.
>
> results = PDirectory.objects.none()
> for d in dirs:
> splitpath = d.path.split("/")
>
> if len(splitpath) == 3: # that would be
> root_dir/sub_dir
> results = results | dirs.filter(id=d.id) #
> This is not efficient
> at all
>
> Thanks,
> Igor
>
>
> On Jan 22, 5:14 pm, Bill Freeman <ke1g...@gmail.com> wrote:
>> 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.
>
>
--
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.
