Re: Q Object Oddity

2007-02-03 Thread Mike Axiak

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]: []
>
> 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
-~--~~~~--~~--~--~---



Re: Q Object Oddity

2007-02-03 Thread [EMAIL PROTECTED]

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]: []

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,
see http://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
-~--~~~~--~~--~--~---



Re: Q Object Oddity

2007-02-03 Thread Russell Keith-Magee

On 2/4/07, Mike Axiak <[EMAIL PROTECTED]> wrote:
>
> Below is the SQL the query,
> User.objects.filter(y|z).distinct().count(),
> generates.
>
> It seems to do the correct OR for the where clauses, and yet still
> uses an INNER JOIN when that type of join is inappropriate for this
> particular query. Is this a known problem? Did I write the queries
> incorrectly?

Depends on what you are trying to do.

The INNER JOIN is a correct interpretation of what you asked Django to
do - Q(registrationprofile__student_info__isnull = False) is
interpreted as 'follow the registrationprofile relation, and on that
related object, check that the value of student_info is not NULL'.

To help solve your problem, it would be helpful to have some more
details. What models are you using to generate this query? What query
are you expecting to see? What results are you expecting to see?

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Q Object Oddity

2007-02-03 Thread Mike Axiak

Below is the SQL the query,
User.objects.filter(y|z).distinct().count(),
generates.

It seems to do the correct OR for the where clauses, and yet still
uses an INNER JOIN when that type of join is inappropriate for this
particular query. Is this a known problem? Did I write the queries
incorrectly?

-Mike


SELECT COUNT(DISTINCT("auth_user"."id"))
FROM "auth_user"

INNER JOIN "program_registrationprofile" AS
"auth_user__registrationprofile"
  ON "auth_user"."id" =
"auth_user__registrationprofile"."user_id"
INNER JOIN "program_satprepreginfo" AS "auth_user__satprepreginfo"
  ON "auth_user"."id" = "auth_user__satprepreginfo"."user_id"
WHERE (
  (
 ("auth_user__registrationprofile"."program_id" = 6 AND
"auth_user__registrationprofile"."student_info_id" IS NOT NULL)

   OR
 "auth_user__satprepreginfo"."program_id" = 6
  )

)

On Feb 3, 6:46 pm, "Mike Axiak" <[EMAIL PROTECTED]> wrote:
> Hey,
> I'm using Django release (currently 0.95.0, waiting for etch to move
> to 0.95.1) with some patches (lazyuser patch comes to mind) on an
> internal development.
>
> The question is, I was trying to do some Q object combinations and was
> met with some weird results:
>
> 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]: []
>
> Note that
>   In [24]: User.objects.filter(y|z).distinct().count()
>   Out[24]: 194L
>
>   In [25]: User.objects.filter(y).distinct().count()
>   Out[25]: 198L
>
> 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?
>
> Any help would be appreciated.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---