Fair enough!
I'll do a workaround.
Thanks,
Göran
On Jul 18, 4:54 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> 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- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
