Re: Django 1.6RC1 exclude behavior change

[Anssi Kääriäinen]

On Monday, November 4, 2013 8:16:12 PM UTC+2, jga...@gmail.com wrote:
>
> I was going to file a ticket in trac about this and found this one(
> https://code.djangoproject.com/ticket/21192) which seems related. The 
> thing is that one was supposedly resolved 5 weeks ago, which would mean 
> that fix would be in 1.6rc1...
> Should I reopen that ticket or file a new one?
>

The issue about multiple filters for same relation in single .exclude() 
query is tracked in #14645.

Just for the record: I don't consider the change in the original report's 
query a release blocker (or a bug at all). The query works differently in 
1.6.x, but as it didn't work correctly in 1.5.x either there is nothing to 
do.

 - Anssi 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a901cb40-b80d-487e-b751-147471c94900%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Model Docs Questions

[Ryan Hiebert]

On Mon, Nov 4, 2013 at 9:31 AM, Andre Terra  wrote:
>
> On Sun, Nov 3, 2013 at 5:13 PM, Cody Scott  wrote:
>>
>> 3
>> Why do Q objects use '&', '|' and '~' for AND, OR and NOT when python uses
>> 'and', 'or' and 'not'?
>> source
>
>
> Because Python actually does use &, | and ~.

The and/or/not operators are meant for flow control, and as such
cannot be overridden to allow us to use them for composing queries.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHSq7dsr-hfuPck_Bk%3DYBu6NCMd3FmW4g7eCKT%2Bgdds_hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6RC1 exclude behavior change

[jgastal]

I was going to file a ticket in trac about this and found this one(
https://code.djangoproject.com/ticket/21192) which seems related. The thing 
is that one was supposedly resolved 5 weeks ago, which would mean that fix 
would be in 1.6rc1...
Should I reopen that ticket or file a new one?

On Monday, November 4, 2013 3:46:04 PM UTC-2, Anssi Kääriäinen wrote:
>
>
>
> On Monday, November 4, 2013 7:24:47 PM UTC+2, jga...@gmail.com wrote:
>>
>> Anssi,
>>
>> Thanks for helping.
>> I'm sorry to say that your answer went somewhat over my head, my 
>> proficiency with SQL is lacking.
>>
>> What I understood from your explanation:
>>  - A filter/exclude that traverses a 1:N relationship(such as foreign 
>> key) should target the same row with all of its criteria(kwargs).
>>  - Complex queries don't work correctly in exclude when using 
>> relationships in 1.5.x
>>  - Complex queries don't work correctly in exclude when using 
>> relationships in 1.6.x
>>
>> Did I understand correctly?
>>
>
> That is a good summary of the situation, except that the exclude bugs are 
> about 1:N (or N:N) relationships, not just any relationship.
>  
>
>> If that was the whole of the situation I would be ok, I can work around 
>> this issue with multiple exclude statements, such as:
>> bees = B.objects.exclude(a__confirmation=False, a__state=1)
>> bees = bees.exclude(a__confirmation__isnull=True, a__state=1)
>> That should be equivalent to what I was trying to do with:
>> confirm_q = Q(a__confirmation=False) | Q(a__confirmation__isnull=True)
>> bees = B.objects.exclude(confirm_q, a__state=1)
>>
>> But my solution of splitting the Q into two queries didn't work, for 
>> either 1.5.5 or 1.6rc1.
>> Did I miss something?
>>
>
> I'd go for a solution where you do:
> a_qs = A.objects.filter(Q(confirmation__isnull=True) | ..., a__state = 
> 1).values_list('b_id')
> bees = B.objects.exclude(pk__in=a_qs)
> If I am not mistaken that is what Django should be doing automatically for 
> you.
>
> Seems like django-users is the right forum to continue this discussion 
> unless there are more items that are about development of Django itself.
>
>  - Anssi
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e67872c-043e-4733-a2a3-c62d55615aee%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6RC1 exclude behavior change

[Anssi Kääriäinen]

On Monday, November 4, 2013 7:24:47 PM UTC+2, jga...@gmail.com wrote:
>
> Anssi,
>
> Thanks for helping.
> I'm sorry to say that your answer went somewhat over my head, my 
> proficiency with SQL is lacking.
>
> What I understood from your explanation:
>  - A filter/exclude that traverses a 1:N relationship(such as foreign key) 
> should target the same row with all of its criteria(kwargs).
>  - Complex queries don't work correctly in exclude when using 
> relationships in 1.5.x
>  - Complex queries don't work correctly in exclude when using 
> relationships in 1.6.x
>
> Did I understand correctly?
>

That is a good summary of the situation, except that the exclude bugs are 
about 1:N (or N:N) relationships, not just any relationship.
 

> If that was the whole of the situation I would be ok, I can work around 
> this issue with multiple exclude statements, such as:
> bees = B.objects.exclude(a__confirmation=False, a__state=1)
> bees = bees.exclude(a__confirmation__isnull=True, a__state=1)
> That should be equivalent to what I was trying to do with:
> confirm_q = Q(a__confirmation=False) | Q(a__confirmation__isnull=True)
> bees = B.objects.exclude(confirm_q, a__state=1)
>
> But my solution of splitting the Q into two queries didn't work, for 
> either 1.5.5 or 1.6rc1.
> Did I miss something?
>

I'd go for a solution where you do:
a_qs = A.objects.filter(Q(confirmation__isnull=True) | ..., a__state = 
1).values_list('b_id')
bees = B.objects.exclude(pk__in=a_qs)
If I am not mistaken that is what Django should be doing automatically for 
you.

Seems like django-users is the right forum to continue this discussion 
unless there are more items that are about development of Django itself.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e98bc270-b991-4246-9cd1-f92464478efb%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Ivan Kharlamov]

On 11/04/2013 04:24 AM, Russell Keith-Magee wrote:
> 
> On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi
> mailto:emanuele.berto...@gmail.com>> wrote:
> 
> I've opened a ticket (#21370) with a proposal for the *inclusion of
> a generic "getter" filter* in the built-in library.
> 
> *Why?*
> 
> Well, because at the moment Django's template system really lacks of
> support for retrieving data from existing context variables in all
> the cases in which the name of the attribute we need is determined
> at execution time.
> 
> 
> It's worth pointing out that this is something the Django core team has
> historically rejected, on the basis that it's a slippery slope from here
> to turning Django's template language into a fully featured programming
> language. So -- fair warning -- the default answer here is going to be
> "No"; it's going to take some convincing to flip that position.
> 
> However, I will admit that this is a use case for which I have some
> sympathy. Cross-cutting arrays of data is one of those things that is a
> lot more complex to do in the context than it would be to do using a
> simple lookup in a template. 
> 
> Formally, I'm probably +0.1 :-)
>  
> 
> *Syntax:*
> 
> {{ object|get:attr_name }}
> 
> Of course the idea is to add a multi-purpose filter which covers
> different use cases (model instances, arbitrary objects, dicts,
> lists, tuples, etc.)
> 
> 
> *IF* we are to add this, I'd be inclined to do this as a primitive of
> the template language itself, rather than as a template filter. This is
> a fundamental concept in context lookup, not a data transformation
> (which is what filters generally represent). 
> 
> The minimal syntactic solution would be to use the colon operator to
> denote arguments in the same way as it does for filters:
> 
>  {{ object:attr_name }}
> 
> or, by introducing square brackets as parseable symbols in the template
> language:
> 
>  {{ object[attr_name] }}
> 
> The latter has the benefit of being compatible with Jinja syntax; the
> downside is that Django templates starts to look even more like a
> programming language.
> 
> Yours, 
> Russ Magee %-)

Hi! I know this is probably wontfix, but I'll bite the bullet and say
that this has less to do with implementing a Turing-complete template
language (which is obviously an issue in a need of urgent attention :-))
and much more to do with template reusability. :-)

Let's say you are working on a system in which users can be assigned
different roles, and, depending on a given role and on the context,  the
user is able to view dynamic number of model fields and attributes.

The most clean and DRY way to work with templates in this situation (as
I see it) is to use a solution similar to the one proposed by the parent
poster.

I'm not even talking about a situation (which you'll obviously consider
much more esoteric) when you have truly dynamic Django models (the ones
that have fields defined by the users during runtime).
`get_FIELD_display` anyone?

I'm not going to say that this is a very big deal, of course, since a
custom template filter is easy to write.

Philosophically speaking, by insisting that this issue should be solved
outside of templates and inside of views, you are putting something that
doesn't belong there, since the parent ticket is about representation
and not about application logic.

Whether his proposal is sufficiently general-purpose to be included in
Django, is another question. I think it is general-purpose.

Best regards,
Ivan

> -- 
> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84_QtcWsop_hPYorOdYUnWxJVVe39E%2Bxu%3DAyUtd3GpP1HQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5277DA5D.80409%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6RC1 exclude behavior change

[jgastal]

I managed to get the desired behavior by doing the following ugly query:
q_obj = (Q(a__confirmation=True) & Q(a__state=1)) | (Q(a__state__gt=1) & 
Q(a__state__lt=1))
bees = B.objects.filter(q_obj)

This is obviously not an ideal solution but is working for me so far...

On Monday, November 4, 2013 3:24:47 PM UTC-2, jga...@gmail.com wrote:
>
> Anssi,
>
> Thanks for helping.
> I'm sorry to say that your answer went somewhat over my head, my 
> proficiency with SQL is lacking.
>
> What I understood from your explanation:
>  - A filter/exclude that traverses a 1:N relationship(such as foreign key) 
> should target the same row with all of its criteria(kwargs).
>  - Complex queries don't work correctly in exclude when using 
> relationships in 1.5.x
>  - Complex queries don't work correctly in exclude when using 
> relationships in 1.6.x
>
> Did I understand correctly?
>
> If that was the whole of the situation I would be ok, I can work around 
> this issue with multiple exclude statements, such as:
> bees = B.objects.exclude(a__confirmation=False, a__state=1)
> bees = bees.exclude(a__confirmation__isnull=True, a__state=1)
> That should be equivalent to what I was trying to do with:
> confirm_q = Q(a__confirmation=False) | Q(a__confirmation__isnull=True)
> bees = B.objects.exclude(confirm_q, a__state=1)
>
> But my solution of splitting the Q into two queries didn't work, for 
> either 1.5.5 or 1.6rc1.
> Did I miss something?
>
> Gastal
>
> On Monday, November 4, 2013 2:43:55 PM UTC-2, Anssi Kääriäinen wrote:
>>
>> On Monday, November 4, 2013 6:06:55 PM UTC+2, Anssi Kääriäinen wrote:
>>>
>>> I'll look into this. 
>>>
>>
>> The situation is that this query didn't work properly in 1.5.x, but this 
>> doesn't work properly in 1.6.x either.
>>
>> The basic problem here is that in 1.5.x .exclude(Q(anything)) didn't work 
>> correctly. Using the example models, try these equivalent queries:
>> bees1 = B.objects.exclude(Q(a__state=1))
>> bees2 = B.objects.exclude(a__state=1)
>>
>> bees1 produces querystr:
>> SELECT "new_basic_b"."id" FROM "new_basic_b" INNER JOIN "new_basic_a" 
>> ON ("new_basic_b"."id" = "new_basic_a"."b_id") WHERE NOT 
>> ("new_basic_a"."state" = 1 )
>>
>> while bees2 produces:
>> SELECT "new_basic_b"."id" FROM "new_basic_b" WHERE NOT 
>> (("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 WHERE 
>> (U1."state" = 1  AND U1."b_id" IS NOT NULL)) AND "new_basic_b"."id" IS NOT 
>> NULL))
>>
>> Note that bees2 has correctly subquery in it. The bees1 query will 
>> produce incorrect results.
>>
>> Now, for the example query, the same "exclude hiding" happens for 
>> Q(a__confirmation=False) | Q(a__confirmation__isnull=True). Due to this the 
>> produced query is:
>> SELECT "new_basic_b"."id" FROM "new_basic_b" LEFT OUTER JOIN 
>> "new_basic_a" ON ("new_basic_b"."id" = "new_basic_a"."b_id") WHERE NOT 
>> (("new_basic_a"."confirmation" = False  OR "new_basic_a"."confirmation" IS 
>> NULL) AND ("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 
>> WHERE (U1."state" = 1  AND U1."b_id" IS NOT NULL)) AND "new_basic_b"."id" 
>> IS NOT NULL))
>>
>> Note the LEFT OUTER JOIN for the ORed condition, but subquery for the 
>> state condition. That is incorrect, both filters should be in the same 
>> subquery.
>>
>> In 1.6.x the situation is, well, different. The generated query is:
>> SELECT "new_basic_b"."id" FROM "new_basic_b" WHERE NOT 
>> (("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 WHERE 
>> U1."confirmation" = False ) OR "new_basic_b"."id" IN (SELECT U0."id" FROM 
>> "new_basic_b" U0 LEFT OUTER JOIN "new_basic_a" U1 ON ( U0."id" = U1."b_id" 
>> ) WHERE U1."confirmation" IS NULL)) AND "new_basic_b"."id" IN (SELECT 
>> U1."b_id" FROM "new_basic_a" U1 WHERE U1."state" = 1 ))
>>
>> Now we have each of the conditions correctly in a subquery, but in 
>> different subqueries which isn't correct (filters inside single 
>> .filter()/.exclude() should target the same row when having multiple 
>> clauses for the same multivalued relation).
>>
>> Complex filters in .exclude() didn't work correctly, and do not work 
>> correctly in the upcoming 1.6 either. If the results were correct in 1.5 
>> that was luck, not a result of Django generating the correct query. It 
>> should be possible to construct data that highlights the problem in the 1.5 
>> version of the query.
>>
>>  - Anssi
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/004e52f5-85e5-4dd2-80ae-57683fa577af%40googlegroups.com.
For more options, visit https://groups.google.com/

Re: Django 1.6RC1 exclude behavior change

[jgastal]

Anssi,

Thanks for helping.
I'm sorry to say that your answer went somewhat over my head, my 
proficiency with SQL is lacking.

What I understood from your explanation:
 - A filter/exclude that traverses a 1:N relationship(such as foreign key) 
should target the same row with all of its criteria(kwargs).
 - Complex queries don't work correctly in exclude when using relationships 
in 1.5.x
 - Complex queries don't work correctly in exclude when using relationships 
in 1.6.x

Did I understand correctly?

If that was the whole of the situation I would be ok, I can work around 
this issue with multiple exclude statements, such as:
bees = B.objects.exclude(a__confirmation=False, a__state=1)
bees = bees.exclude(a__confirmation__isnull=True, a__state=1)
That should be equivalent to what I was trying to do with:
confirm_q = Q(a__confirmation=False) | Q(a__confirmation__isnull=True)
bees = B.objects.exclude(confirm_q, a__state=1)

But my solution of splitting the Q into two queries didn't work, for either 
1.5.5 or 1.6rc1.
Did I miss something?

Gastal

On Monday, November 4, 2013 2:43:55 PM UTC-2, Anssi Kääriäinen wrote:
>
> On Monday, November 4, 2013 6:06:55 PM UTC+2, Anssi Kääriäinen wrote:
>>
>> I'll look into this. 
>>
>
> The situation is that this query didn't work properly in 1.5.x, but this 
> doesn't work properly in 1.6.x either.
>
> The basic problem here is that in 1.5.x .exclude(Q(anything)) didn't work 
> correctly. Using the example models, try these equivalent queries:
> bees1 = B.objects.exclude(Q(a__state=1))
> bees2 = B.objects.exclude(a__state=1)
>
> bees1 produces querystr:
> SELECT "new_basic_b"."id" FROM "new_basic_b" INNER JOIN "new_basic_a" 
> ON ("new_basic_b"."id" = "new_basic_a"."b_id") WHERE NOT 
> ("new_basic_a"."state" = 1 )
>
> while bees2 produces:
> SELECT "new_basic_b"."id" FROM "new_basic_b" WHERE NOT 
> (("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 WHERE 
> (U1."state" = 1  AND U1."b_id" IS NOT NULL)) AND "new_basic_b"."id" IS NOT 
> NULL))
>
> Note that bees2 has correctly subquery in it. The bees1 query will produce 
> incorrect results.
>
> Now, for the example query, the same "exclude hiding" happens for 
> Q(a__confirmation=False) | Q(a__confirmation__isnull=True). Due to this the 
> produced query is:
> SELECT "new_basic_b"."id" FROM "new_basic_b" LEFT OUTER JOIN 
> "new_basic_a" ON ("new_basic_b"."id" = "new_basic_a"."b_id") WHERE NOT 
> (("new_basic_a"."confirmation" = False  OR "new_basic_a"."confirmation" IS 
> NULL) AND ("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 
> WHERE (U1."state" = 1  AND U1."b_id" IS NOT NULL)) AND "new_basic_b"."id" 
> IS NOT NULL))
>
> Note the LEFT OUTER JOIN for the ORed condition, but subquery for the 
> state condition. That is incorrect, both filters should be in the same 
> subquery.
>
> In 1.6.x the situation is, well, different. The generated query is:
> SELECT "new_basic_b"."id" FROM "new_basic_b" WHERE NOT 
> (("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 WHERE 
> U1."confirmation" = False ) OR "new_basic_b"."id" IN (SELECT U0."id" FROM 
> "new_basic_b" U0 LEFT OUTER JOIN "new_basic_a" U1 ON ( U0."id" = U1."b_id" 
> ) WHERE U1."confirmation" IS NULL)) AND "new_basic_b"."id" IN (SELECT 
> U1."b_id" FROM "new_basic_a" U1 WHERE U1."state" = 1 ))
>
> Now we have each of the conditions correctly in a subquery, but in 
> different subqueries which isn't correct (filters inside single 
> .filter()/.exclude() should target the same row when having multiple 
> clauses for the same multivalued relation).
>
> Complex filters in .exclude() didn't work correctly, and do not work 
> correctly in the upcoming 1.6 either. If the results were correct in 1.5 
> that was luck, not a result of Django generating the correct query. It 
> should be possible to construct data that highlights the problem in the 1.5 
> version of the query.
>
>  - Anssi
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e3398719-7be8-4624-9bac-717dd1553612%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6RC1 exclude behavior change

[Anssi Kääriäinen]

On Monday, November 4, 2013 6:06:55 PM UTC+2, Anssi Kääriäinen wrote:
>
> I'll look into this. 
>

The situation is that this query didn't work properly in 1.5.x, but this 
doesn't work properly in 1.6.x either.

The basic problem here is that in 1.5.x .exclude(Q(anything)) didn't work 
correctly. Using the example models, try these equivalent queries:
bees1 = B.objects.exclude(Q(a__state=1))
bees2 = B.objects.exclude(a__state=1)

bees1 produces querystr:
SELECT "new_basic_b"."id" FROM "new_basic_b" INNER JOIN "new_basic_a" 
ON ("new_basic_b"."id" = "new_basic_a"."b_id") WHERE NOT 
("new_basic_a"."state" = 1 )

while bees2 produces:
SELECT "new_basic_b"."id" FROM "new_basic_b" WHERE NOT 
(("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 WHERE 
(U1."state" = 1  AND U1."b_id" IS NOT NULL)) AND "new_basic_b"."id" IS NOT 
NULL))

Note that bees2 has correctly subquery in it. The bees1 query will produce 
incorrect results.

Now, for the example query, the same "exclude hiding" happens for 
Q(a__confirmation=False) | Q(a__confirmation__isnull=True). Due to this the 
produced query is:
SELECT "new_basic_b"."id" FROM "new_basic_b" LEFT OUTER JOIN 
"new_basic_a" ON ("new_basic_b"."id" = "new_basic_a"."b_id") WHERE NOT 
(("new_basic_a"."confirmation" = False  OR "new_basic_a"."confirmation" IS 
NULL) AND ("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 
WHERE (U1."state" = 1  AND U1."b_id" IS NOT NULL)) AND "new_basic_b"."id" 
IS NOT NULL))

Note the LEFT OUTER JOIN for the ORed condition, but subquery for the state 
condition. That is incorrect, both filters should be in the same subquery.

In 1.6.x the situation is, well, different. The generated query is:
SELECT "new_basic_b"."id" FROM "new_basic_b" WHERE NOT 
(("new_basic_b"."id" IN (SELECT U1."b_id" FROM "new_basic_a" U1 WHERE 
U1."confirmation" = False ) OR "new_basic_b"."id" IN (SELECT U0."id" FROM 
"new_basic_b" U0 LEFT OUTER JOIN "new_basic_a" U1 ON ( U0."id" = U1."b_id" 
) WHERE U1."confirmation" IS NULL)) AND "new_basic_b"."id" IN (SELECT 
U1."b_id" FROM "new_basic_a" U1 WHERE U1."state" = 1 ))

Now we have each of the conditions correctly in a subquery, but in 
different subqueries which isn't correct (filters inside single 
.filter()/.exclude() should target the same row when having multiple 
clauses for the same multivalued relation).

Complex filters in .exclude() didn't work correctly, and do not work 
correctly in the upcoming 1.6 either. If the results were correct in 1.5 
that was luck, not a result of Django generating the correct query. It 
should be possible to construct data that highlights the problem in the 1.5 
version of the query.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ac93df2-e2fe-441c-9060-b3f672a2f8cc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

RE: Django 1.6RC1 exclude behavior change

[Kääriäinen Anssi]

I'll look into this.

 - Anssi

From: django-developers@googlegroups.com [django-developers@googlegroups.com] 
On Behalf Of jgas...@gmail.com [jgas...@gmail.com]
Sent: Monday, November 04, 2013 17:16
To: django-developers@googlegroups.com
Subject: Django 1.6RC1 exclude behavior change

I've found what looks like a serious behavior change in the exclude queryset 
method from Django 1.5.5 to Django 1.6 rc1.

It seems that on 1.5.5 exclude when traversing relationships only excluded 
items if all criteria on the kwargs were matched on the same related item. On 
1.6rc1 it excludes items even if the criteria on the kwargs is only matched 
across multiple related items. I guess this explanation is not very clear, so 
here is a sample code that show the behavior change:
http://pastebin.kde.org/pe1vlzd3v

Since I didn't find anything on the change notes about this, it looks to me 
like a bug. Is it? Or am I missing something?

--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8267eeb8-f1a7-46db-969e-79d819c8f797%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FDD0C28683BA024195713874AF8663B31C6F86DC6E%40EXMAIL.stakes.fi.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Model Docs Questions

[Andre Terra]

On Sun, Nov 3, 2013 at 5:13 PM, Cody Scott  wrote:

> 3
> Why do Q objects use '&', '|' and '~' for AND, OR and NOT when python uses
> 'and', 'or' and 'not'?
> source
>

Because Python actually does use &, | and ~.

See the following links for more info:
https://wiki.python.org/moin/BitwiseOperators
http://en.wikipedia.org/wiki/Bitwise_operation
http://docs.python.org/3.4/library/operator.html#mapping-operators-to-functions



Cheers,
AT

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKBiv3zUHz49MDjUYyuRidx_xp0uX8bmeLY8SkY%3DqgLLXigzjg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Aymeric Augustin]

2013/11/4 Jonathan Slenders 

> there's probably a reason


History.

The drawbacks of deprecating it at this point are large compared to the
benefits.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mVPkDfRLnbLbhr3y1sDAsYn0M9o-MWspnALTLZ-%3D4FR_g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Django 1.6RC1 exclude behavior change

[jgastal]

I've found what looks like a serious behavior change in the exclude 
queryset method from Django 1.5.5 to Django 1.6 rc1.

It seems that on 1.5.5 exclude when traversing relationships only excluded 
items if all criteria on the kwargs were matched on the same related item. 
On 1.6rc1 it excludes items even if the criteria on the kwargs is only 
matched across multiple related items. I guess this explanation is not very 
clear, so here is a sample code that show the behavior change:
http://pastebin.kde.org/pe1vlzd3v

Since I didn't find anything on the change notes about this, it looks to me 
like a bug. Is it? Or am I missing something?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8267eeb8-f1a7-46db-969e-79d819c8f797%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Jonathan Slenders]

Le lundi 4 novembre 2013 14:13:44 UTC+1, Emanuele Bertoldi a écrit :

> What about the *add* filter? ;) 
>

I forgot about that one.

However, there's probably a reason. It's hard to fix the templating engine 
and implement a "+" operator. Because people would expect that whitespace 
around the "+" should be possible. But that destroys almost all the 
template tags now, because we first do token.split_contents in practically 
every template tag, end then do var.resolve() on every part. Actually, 
var.resolve() should receive the whole string. I think it should even 
evaluate the "==" operator, what is done in the {% if %} tag now. (and the 
length_is filter)

It's of course possible to add a "+" operator and allow all the built-in 
tags to use it in var.resolve(), but it will take forever until all 
external template tags have been fixed. People will expect the "+" to work 
in any context.

I had a backwards-compatible patch to make writing template tags easier and 
more consistent. I'd like to work toward such a consistent context free 
grammar. The patches are from half a year ago, so not sure whether it 
merges, but reviews are welcome.
https://code.djangoproject.com/ticket/20434


b.t.w, if we implement the []-operator, we can maybe use that for slicing 
as well, instead of the slice filter that we have right now.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/47ed653f-9dbd-46c2-8d44-74c3fef4ac09%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Emanuele Bertoldi]

Russell Keith-Magee wrote:

> It's worth pointing out that this is something the Django core team has 
> historically rejected, on the basis that it's a slippery slope from here to 
> turning Django's template language into a fully featured programming 
> language. So -- fair warning -- the default answer here is going to be 
> "No"; it's going to take some convincing to flip that position.
>
> However, I will admit that this is a use case for which I have some 
> sympathy. Cross-cutting arrays of data is one of those things that is a lot 
> more complex to do in the context than it would be to do using a simple 
> lookup in a template. 
>
> Formally, I'm probably +0.1 :-)
>

Well, I understand the point but I don't honestly could think to attribute 
lookup as an exclusive feature of "programming languages". 

At the end we're talking about "getting" information, not "setting": if you 
want to show them, you need to retrieve them from somewhere. That's my 
humble opinion and, maybe, a good general principle to distinguish between 
what should be included in template system and what not (then, of course, 
there're always exceptions).
 

> *IF* we are to add this, I'd be inclined to do this as a primitive of the 
> template language itself, rather than as a template filter. This is a 
> fundamental concept in context lookup, not a data transformation (which is 
> what filters generally represent). 
>
> The minimal syntactic solution would be to use the colon operator to 
> denote arguments in the same way as it does for filters:
>
>  {{ object:attr_name }}
>
> or, by introducing square brackets as parseable symbols in the template 
> language:
>
>  {{ object[attr_name] }}
>
> The latter has the benefit of being compatible with Jinja syntax; the 
> downside is that Django templates starts to look even more like a 
> programming language.
>

That would be awesome. 

Jonathan Slenders wrote:

> - The only operators that we should implement are those necessary for data 
> lookups. We shouldn't implement addition or subtraction operators for 
> example.
>

What about the *add* filter? ;) 

Again, we have to remember that in programming there are always exceptions. 
Be too strict to just a theoretical principle could really miss the contact 
with the reality. Frankly speaking, I understand that we don't need another 
programming language for templates but the "with" statement and the already 
cited "add" filter are examples of exceptions at the rule to make the 
template system something realistically useful (do I have to mention all 
the CSS frameworks, sessions/cookies and the new features of HTML5 on 
storage-side as references to the historical failing of too-strict 
markup-only ideas in real world?)

Cheers,
Emanuele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c7d3dfea-7e83-4922-af21-f1b065aa4845%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Jonathan Slenders]

Rusell's last proposal, using the square brackets sounds the best and 
future proof to me. I think it should be something different from the 
calling syntax of template tags, because calling of an object or retrieving 
a property is not the same.

While I like it, I don't say we should necessarily allow it, but the square 
brackets allow for nesting. e.g.

{{ object[attribute.name] }}

or even:

{{ object[attributes[something].name] }}


Semantically, the following tree are the same:

{{ object.name }}

{{ object["name"] }}

{% with "name" as var %} {{ object[var] }} {% endwith %}

Another reason for using another syntax for filters and attribute lookups 
is that I think it can be possible in the future to use any arbitrary 
object from the context as a filter.
Say, for instance that from a view, we put a dictionary of filters in the 
context. The following would be possible.

{% my_var|my_filters["escape"]:param %}


As said, we should be careful not to create a complete programming 
language. For me, that means:
- Template tags should never cause side effects. (They should not be able 
to change anything in the database or anywhere else. However, that's hard 
to force!)
- The only operators that we should implement are those necessary for data 
lookups. We shouldn't implement addition or subtraction operators for 
example.
- The template author shouldn't have to care whether the attribute lookup 
happens in a dictionary (through getitem) or in an object (through getattr).
- The template author shouldn't be concerned with how expensive some 
attribute lookups are, for instance when an attribute lookup causes a 
database query. (That's also a hard one, we cannot make all lookups cheap, 
or forbid expensive lookups.)

I think in order to avoid that many projects will create their own template 
filters and template tags as workarounds to syntax limitations, we really 
shouldn't artificially limit the syntax to the most obvious lookups. (I'm 
rather against the idea of custom template tags, but not against filters.)

B.t.w. if anyone has template engine related patches ready, I'm always 
willing to review it.

Cheers,
Jonathan



Le lundi 4 novembre 2013 01:24:45 UTC+1, Russell Keith-Magee a écrit :
>
>
> On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi 
> 
> > wrote:
>
>> I've opened a ticket (#21370) with a proposal for the *inclusion of a 
>> generic "getter" filter* in the built-in library.
>>
>> *Why?*
>>
>> Well, because at the moment Django's template system really lacks of 
>> support for retrieving data from existing context variables in all the 
>> cases in which the name of the attribute we need is determined at execution 
>> time.
>>
>
> It's worth pointing out that this is something the Django core team has 
> historically rejected, on the basis that it's a slippery slope from here to 
> turning Django's template language into a fully featured programming 
> language. So -- fair warning -- the default answer here is going to be 
> "No"; it's going to take some convincing to flip that position.
>
> However, I will admit that this is a use case for which I have some 
> sympathy. Cross-cutting arrays of data is one of those things that is a lot 
> more complex to do in the context than it would be to do using a simple 
> lookup in a template. 
>
> Formally, I'm probably +0.1 :-)
>  
>
>> *Syntax:*
>>
>> {{ object|get:attr_name }}
>>
>> Of course the idea is to add a multi-purpose filter which covers 
>> different use cases (model instances, arbitrary objects, dicts, lists, 
>> tuples, etc.)
>>
>
> *IF* we are to add this, I'd be inclined to do this as a primitive of the 
> template language itself, rather than as a template filter. This is a 
> fundamental concept in context lookup, not a data transformation (which is 
> what filters generally represent). 
>
> The minimal syntactic solution would be to use the colon operator to 
> denote arguments in the same way as it does for filters:
>
>  {{ object:attr_name }}
>
> or, by introducing square brackets as parseable symbols in the template 
> language:
>
>  {{ object[attr_name] }}
>
> The latter has the benefit of being compatible with Jinja syntax; the 
> downside is that Django templates starts to look even more like a 
> programming language.
>
> Yours, 
> Russ Magee %-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7a3368e7-1e89-4433-b390-b0ad7a30ef3c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.