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 <[email protected]> wrote:
> On Fri, Jan 22, 2010 at 10:22 AM, Igor <[email protected]> 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 [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-users?hl=en.
