On Fri, 2008-07-18 at 04:11 -0700, Göran Åström wrote:
> Thank you for answering and for the workaround tip.
> I agree, exclude should be the complement of filter. This did not work
> in 0.96 but works now, which is great.
> I don't think however that it is a good idea to let filter(~Q()) mean
> 'not exists', i.e. be equivalent to 'exclude', for multi valued
> relations, while it means 'not' in other cases.
> It would be nice if ~Q also for these relations could mean 'not',
> which is sometimes needed (as is 'and', 'or' and parenthesis) when
> creating expressions.
Lots of things would be nice, but if we made that change, ~Q would not
be the opposite of Q() -- which is a filter() equivalent -- and that
would be a little inconsistent in other respects.
> In my opinion if Entry.objects.filter(~Q(condition)) gives a set of
> entries then Blog.objects.filter(~Q(entry__condition)) should give the
> blogs of these entries, while
> Blog.objects.exclude(~Q(entry__condition)) should give the
> complementary blogs, just as the case is without the ~ characters.
As I've agreed, different interpretations are always going to be
possible. We've chosen a very consistent set in the way that exclude()
and filter() and ~Q are implemented and whilst they aren't the only
possible ones, as indicated by your alternative proposal above, I don't
think your alternative is a better approach than what we have now. I
don't agree with the logic about Entry.filteR() mapping to Blog.filter()
for multi-valued return results. When you extrapolate that to other
multi-valued situations, including filtering on many-to-many, things get
a little unintuitive.
So let's stick with what we've got now and move on. Hopefully you can
appreciate that what Django is doing is still logical, even if you don't
agree with the choice we've made, and you can see that there are
multiple possibilities, so we had to choose one.
Regards,
Malcolm
>
> Regards,
> Göran
>
> On Jul 17, 6:49 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > On Thu, 2008-07-17 at 02:39 -0700, Göran Åström wrote:
> > > In my view the 'not' can be interpreted differently.
> > > Look at the following requests:
> >
> > > 1. Give me blogs with entries matching a criteria.
> > > 2. Give me blogs with entries not matching a criteria.
> > > 3. Give me blogs without entries matching a criteria.
> >
> > Whilst alternate interpretations are always possible, interpreting
> > exclude as the complement of include ("filter") is the most natural. So
> > excluding based on a particular entry means to take the whole set of
> > blogs and remove those containing an entry that matches the condition
> > (since the filter() version would be those blogs containing an entry
> > that match the condition). Thus exclude() and filter() are opposites.
> >
> > Since (a) writing your own Q-like object is possible and not
> > particularly hard and (b) nested queries are more or less supported (the
> > API doesn't exist, but all the under-the-cover implementation is there
> > and it's possible to use it if you read the code), your second option
> > has at least two ways to be accessed. So keeping the most natural
> > version of exclude() that we have now still seems like the best option
> > to me. That way, nothing is impossible and the obvious usage is the
> > right one.
> >
> > Regards,
> > Malcolm
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
