Hello, I'm surprised this is marked as a "do not fix" bug. I mean, essentially these Q objects will at the end of the day define sets of objects, and it doesn't seem expected behavior to me to say a OR b is a subset of b. Currently I am working around this by explicitly taking IDs, and doing ors and ands with IN.
While I know that the query follows the key and finds registrationprofile, and some users do not have it, that is precisely what I think is going wrong. That is, in the python usage sense (that is, away from SQL), I told django to use OR. It then interpreted this and used two inner joins, which IMHO is an incorrect interpretation. -Mike On Feb 3, 8:15 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi, > > On 4 Lut, 00:46, "Mike Axiak" <[EMAIL PROTECTED]> wrote: > > > y = Q(satprepreginfo__program = program) > > > z = Q(registrationprofile__program = program) & \ > > Q(registrationprofile__student_info__isnull = False) > > > This is my result: > > > In [27]: User.objects.filter(y | z).filter(username = 'mlopes') > > Out[27]: [] > > > In [28]: User.objects.filter(y).filter(username = 'mlopes') > > Out[28]: [<User: mlopes>] > > This probably means that user mlopes does not have a > RegistrationProfile. > > The registrationprofile__something lookups are done using INNER JOIN > so adding such a condition filters out all users that do not have > corresponding entries in registrationprofile table. You need OUTER > (or LEFT) JOINS to make this work like you would expect. > > > So I am getting something as a result, but I just chose to filter one > > user that has an interesting property. > > Question: Am I doing something wrong? Is this a bug/feature/expected > > behavior? > > It is the expected behavior with current implementation of field > lookups -- they don't provide a nice way to request an outer join. > There was at least one patch to fix it, currently marked as wontfix, > seehttp://code.djangoproject.com/ticket/2922 > > You can also do it without patching Django by creating a custom Q > object, but it is not too easy or elegant either. If you don't mind > patching Django then #2922 might be a better idea. > > -mk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
