Re: [Django] #28838: annotations + base_manager_name + instance.save() raises exception

[Django]

#28838: annotations + base_manager_name + instance.save() raises exception
-+-
 Reporter:  James Addison|Owner:
 |  shangdahao
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shangdahao):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/9587 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.72dc6d59375525442a0b6dfa123f951a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29022: HashedFilesMixin does not properly skip protocol-relative urls

[Django]

#29022: HashedFilesMixin does not properly skip protocol-relative urls
---+
   Reporter:  Will Gulian  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.staticfiles  |Version:  2.0
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 While protocol-relative urls have been deprecated it would be nice for
 Django staticfiles to support it since a lot of code still uses it or
 explicitly ''not'' support it. Right now the relevant snippet implies that
 the code does filter out protocol-relative urls but it currently does not:
 {{{#!python
 # django/contrib/staticfiles/storage.py

 # Ignore absolute/protocol-relative and data-uri URLs.
 if re.match(r'^[a-z]+:', url):
 return matched
 }}}

 I've included an example snippet that uses a protocol-relative url but is
 not filtered:

 {{{#!css
  @import
 
url("//fonts.googleapis.com/css?family=Source+Sans+Pro:400,700|Raleway:400,800,900");
   }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.45d5faaf70e389235aee8fe905a7388e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28911: Add support for the Msft time zone required on Windows Subsystem for Linux running openSUSE (was: Add support for the Msft time zone required on Windows Subsystem for Linux)

[Django]

#28911: Add support for the Msft time zone required on Windows Subsystem for 
Linux
running openSUSE
--+
 Reporter:  El'endia Starman  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  timezone  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Stephen James):

 * cc: Stephen James (added)


Old description:

> Under Windows Subsystem for Linux (I was using openSUSE), the only
> available time zone is `Msft`, which uses settings that are set on the
> Windows side. This is not a valid time zone in pytz. In the process of
> reporting an error thrown by a bug in my code, Django tried to normalize
> the time zone provided in the project settings by passing it through
> pytz. pytz then complains that the time zone is unknown. Somewhat
> amusingly, this error is also caught by Django and goes through the same
> code path, quickly hitting the recursion limit.
>
> See below for a significant part of the stack trace. My temporary
> solution was to change
>
> `return pytz.timezone(settings.TIME_ZONE)`
>
> to
>
> `return pytz.timezone(settings.TIME_ZONE if settings.TIME_ZONE in
> pytz.all_timezones else 'UTC')`
>
> ---
>
> {{{
> pytz.exceptions.UnknownTimeZoneError: 'Msft'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/core/handlers/exception.py", line 41, in inner
> response = get_response(request)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/utils/deprecation.py", line 140, in __call__
> response = self.get_response(request)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/core/handlers/exception.py", line 43, in inner
> response = response_for_exception(request, exc)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/core/handlers/exception.py", line 93, in
> response_for_exception
> response = handle_uncaught_exception(request,
> get_resolver(get_urlconf()), sys.exc_info())
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/core/handlers/exception.py", line 139, in
> handle_uncaught_exception
> return debug.technical_500_response(request, *exc_info)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/views/debug.py", line 84, in technical_500_response
> html = reporter.get_traceback_html()
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/views/debug.py", line 328, in get_traceback_html
> return t.render(c)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/template/base.py", line 207, in render
> return self._render(context)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/template/base.py", line 199, in _render
> return self.nodelist.render(context)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/template/base.py", line 990, in render
> bit = node.render_annotated(context)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/template/base.py", line 957, in render_annotated
> return self.render(context)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/template/base.py", line 1040, in render
> output = self.filter_expression.resolve(context)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/template/base.py", line 732, in resolve
> obj = template_localtime(obj, context.use_tz)
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/utils/timezone.py", line 195, in template_localtime
> return localtime(value) if should_convert else value
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/utils/timezone.py", line 213, in localtime
> timezone = get_current_timezone()
>   File "/home/elendiastarman/.virtualenvs/django/lib/python3.4/site-
> packages/django/utils/timezone.py", line 97, in get_current_timezone
> return getattr(_active, "value", get_default_timezone())
>   File
> "/home/elendiastarman/.virtualenvs/django/lib64/python3.4/functools.py",
> line 472, in wrapper
> result = user_function(

Re: [Django] #28757: Allow using forms of contrib.auth without installing contrib.auth

[Django]

#28757: Allow using forms of contrib.auth without installing contrib.auth
-+-
 Reporter:  Sagar Chalise|Owner:
 Type:   |  shangdahao
  Cleanup/optimization   |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  auth forms apps  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>


Comment:

 After this commit, there are some errors when running `$
 ./tests/runtests.py auth_tests.test_management` (but adding `--reverse`
 fixes it). shangdahao, can you debug that?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.61383391f2db735eb9b00d8f8da91f6c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28542: migration that introduces uuid field is not reversible with unique=True

[Django]

#28542: migration that introduces uuid field is not reversible with unique=True
+--
 Reporter:  karyon  |Owner:  Tim Martin
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"02365d3f38a64a5c2f3e932f23925a381d5bb151" 02365d3]:
 {{{
 #!CommitTicketReference repository=""
 revision="02365d3f38a64a5c2f3e932f23925a381d5bb151"
 Fixed #28542 -- Fixed deletion of primary key constraint if the new field
 is unique.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dba7b2a3ebaf9b65f818691a75de3652%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
 Reporter:  Paul |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  django-model,| Triage Stage:
  foreign-key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ramiro Morales):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 Are you actually seeing this in Django 1.10 as per the ticket field? If so
 please try to test it on a newer version, e.g. 1.11 or even better 2.0.
 For two reasons: Django 1.10 support period has finished
 (https://www.djangoproject.com/weblog/2015/jun/25/roadmap/) and it could
 be this is a problem which is already solved.

 What database backend are you using? Please reopen when you can provide
 this information.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2625b12384cf7c9cc896e6240dce6d87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28881: Document that CommonPasswordValidator assumes all words are lower case

[Django]

#28881: Document that CommonPasswordValidator assumes all words are lower case
--+
 Reporter:  Nick Farrell  |Owner:  Karmen
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Karmen):

 * owner:  nobody => Karmen
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.1c2987c049e223ac5779893c86197908%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28542: migration that introduces uuid field is not reversible with unique=True

[Django]

#28542: migration that introduces uuid field is not reversible with unique=True
+--
 Reporter:  karyon  |Owner:  Tim Martin
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by karyon):

 ping - this seems to be essentially done?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e90b54d9025c8532c6540ff27007fb62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28761: Document prefixes in InlineFormsets

[Django]

#28761: Document prefixes in InlineFormsets
-+-
 Reporter:  Jay Welborn  |Owner:  Jay
 Type:   |  Welborn
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  InlineFormsets   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"e5acbbe18e1f6840cea0c6f37f4ac7bfbdb04acc" e5acbbe]:
 {{{
 #!CommitTicketReference repository=""
 revision="e5acbbe18e1f6840cea0c6f37f4ac7bfbdb04acc"
 [2.0.x] Fixed #28761 -- Documented how an inline formset's prefix works.

 Backport of 56e590cc0be4d8c8b6fe0967583a6e02d18ee03e from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a68d662c6de03a1f4d3eaa11c9dd137f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28761: Document prefixes in InlineFormsets

[Django]

#28761: Document prefixes in InlineFormsets
-+-
 Reporter:  Jay Welborn  |Owner:  Jay
 Type:   |  Welborn
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  InlineFormsets   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"56e590cc0be4d8c8b6fe0967583a6e02d18ee03e" 56e590cc]:
 {{{
 #!CommitTicketReference repository=""
 revision="56e590cc0be4d8c8b6fe0967583a6e02d18ee03e"
 Fixed #28761 -- Documented how an inline formset's prefix works.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.24e2627823e9c1cfa9e0b62a573fdb46%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28944: Chaining values()/values_list() after QuerySet.select_for_update(of=()) crashes

[Django]

#28944: Chaining values()/values_list() after QuerySet.select_for_update(of=())
crashes
-+-
 Reporter:  Thierry Bastian  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 It could be acceptable (at least as a temporary measure) to raise a
 message that it's not supported.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.86fdb975792beb84dce6cd4252e0ea3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28944: Chaining values()/values_list() after QuerySet.select_for_update(of=()) crashes

[Django]

#28944: Chaining values()/values_list() after QuerySet.select_for_update(of=())
crashes
-+-
 Reporter:  Thierry Bastian  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ran Benita):

 I'm afraid this case is harder. Essentially, the current implementation of
 select_for_update(of=(...)) is based on the select_related()
 infrastructure, but of course once .values()/.values_list() is invoked
 there is no more select_related.

 I will try to dig deeper once I am able. Help is welcome.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ef0a865fd1eaac467ba822494f82c2ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
 Reporter:  Paul |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django-model,| Triage Stage:
  foreign-key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paul):

 Replying to [comment:4 Tim Graham]:
 > Is that the simplest queryset that demonstrates the issue?

 The simplest will be with three words:
 {{{
 Sentence.objects.annotate(n=Count('tokens',
 
distinct=True)).filter(n=5).filter(tokens__name__in=['se']).annotate(n0=F('tokens')).filter(tokens__name__in=['faire']).annotate(n1=F('tokens')).filter(tokens__name__in=['un']).annotate(n2=F('tokens'))
 }}}


 Query:


 {{{
 SELECT "sentence"."id", "sentence"."name", COUNT(DISTINCT
 "token"."id") AS "n", T3."id" AS "n0", T4."id" AS "n1", T4."id" AS "n2"
 FROM "sentence" LEFT OUTER JOIN "token" ON ("sentence"."id" =
 "token"."sentence_id") INNER JOIN "token" T3 ON ("sentence"."id" =
 T3."sentence_id") INNER JOIN "token" T4 ON ("sentence"."id" =
 T4."sentence_id") INNER JOIN "token" T5 ON ("sentence"."id" =
 T5."sentence_id") WHERE (T3."name" IN (se) AND T4."name" IN (faire) AND
 T5."name" IN (un)) GROUP BY "word_frword"."id", T3."id", T4."id" HAVING
 COUNT(DISTINCT "token"."id") = 5
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.253e6234311a37834777406d4a5773db%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
 Reporter:  Paul |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django-model,| Triage Stage:
  foreign-key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Is that the simplest queryset that demonstrates the issue?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ac88a802e72d796391b3e8c013f49283%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
 Reporter:  Paul |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django-model,| Triage Stage:
  foreign-key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Paul:

Old description:

> {{{
> class Sentence(Model):
> name = CharField()
>
> class Tokens(Model):
> token = CharField()
> sentence = ForeignKey(Sentence, related_name='tokens')
> }}}
>

>
> {{{
> Sentence.objects.annotate(n=Count('tokens',
> distinct=True)).filter(n=5).filter(tokens__name__in=['se']).annotate(n0=F('tokens')).filter(tokens__name__in=['faire']).annotate(n1=F('tokens')).filter(tokens__name__in=['faire']).annotate(n2=F('tokens')).filter(tokens__name__in=['un']).annotate(n3=F('tokens')).filter(tokens__name__in=['avoir']).annotate(n4=F('tokens'))
> }}}
>

> Above code generates the following query:
>

> {{{
> SELECT "sentence"."id", "sentence"."name" COUNT(DISTINCT
> "token"."id") AS "n", T3."id" AS "n0", T4."id" AS "n1", T4."id" AS "n2",
> T6."id" AS "n3", T6."id" AS "n4" FROM "sentence" LEFT OUTER JOIN "token"
> ON ("sentence"."id" = "token"."sentence_id") INNER JOIN "token" T3 ON
> ("sentence"."id" = T3."sentence_id") INNER JOIN "token" T4 ON
> ("sentence"."id" = T4."sentence_id") INNER JOIN "token" T5 ON
> ("sentence"."id" = T5."sentence_id") INNER JOIN "token" T6 ON
> ("sentence"."id" = T6."sentence_id") INNER JOIN "token" T7 ON
> ("sentence"."id" = T7."sentence_id") WHERE (T3."name" IN (se) AND
> T4."name" IN (faire) AND T5."name" IN (un) AND T6."name" IN (avoir) AND
> T7."name" IN (faire)) GROUP BY "word_frword"."id", T3."id", T4."id",
> T6."id" HAVING COUNT(DISTINCT "token"."id") = 5
> }}}
>

> There is no `T4."id" AS "n2"` instead of `T5."id" AS "n2"`, so chaining
> is working incorrectly.

New description:

 {{{
 class Sentence(Model):
 name = CharField()

 class Tokens(Model):
 token = CharField()
 sentence = ForeignKey(Sentence, related_name='tokens')
 }}}



 {{{
 Sentence.objects.annotate(n=Count('tokens',
 
distinct=True)).filter(n=5).filter(tokens__name__in=['se']).annotate(n0=F('tokens')).filter(tokens__name__in=['faire']).annotate(n1=F('tokens')).filter(tokens__name__in=['faire']).annotate(n2=F('tokens')).filter(tokens__name__in=['un']).annotate(n3=F('tokens')).filter(tokens__name__in=['avoir']).annotate(n4=F('tokens'))
 }}}


 Above code generates the following query:


 {{{
 SELECT "sentence"."id", "sentence"."name" COUNT(DISTINCT "token"."id")
 AS "n", T3."id" AS "n0", T4."id" AS "n1", T4."id" AS "n2", T6."id" AS
 "n3", T6."id" AS "n4" FROM "sentence" LEFT OUTER JOIN "token" ON
 ("sentence"."id" = "token"."sentence_id") INNER JOIN "token" T3 ON
 ("sentence"."id" = T3."sentence_id") INNER JOIN "token" T4 ON
 ("sentence"."id" = T4."sentence_id") INNER JOIN "token" T5 ON
 ("sentence"."id" = T5."sentence_id") INNER JOIN "token" T6 ON
 ("sentence"."id" = T6."sentence_id") INNER JOIN "token" T7 ON
 ("sentence"."id" = T7."sentence_id") WHERE (T3."name" IN (se) AND
 T4."name" IN (faire) AND T5."name" IN (un) AND T6."name" IN (avoir) AND
 T7."name" IN (faire)) GROUP BY "word_frword"."id", T3."id", T4."id",
 T6."id" HAVING COUNT(DISTINCT "token"."id") = 5
 }}}


 There is `T4."id" AS "n2"` instead of `T5."id" AS "n2"`, so chaining is
 working incorrectly.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.88ae3be6cde53a622cbf8d16d7126385%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
 Reporter:  Paul |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django-model,| Triage Stage:
  foreign-key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paul):

 * status:  closed => new
 * resolution:  invalid =>


Old description:

> {{{
> class Sentence(Model):
> name = CharField()
>
> class Tokens(Model):
> token = CharField()
> sentence = ForeignKey(Sentence, related_name='tokens')
> }}}
>

>
> {{{
> Sentence.objects.annotate(n=Count('tokens',
> distinct=True)).filter(n=5).filter(tokens__name__in=['se']).annotate(n0=F('tokens')).filter(tokens__name__in=['faire']).annotate(n1=F('tokens')).filter(tokens__name__in=['faire']).annotate(n2=F('tokens')).filter(tokens__name__in=['un']).annotate(n3=F('tokens')).filter(tokens__name__in=['avoir']).annotate(n4=F('tokens'))
> }}}
>

> Above code generates the following query:
>

> {{{
> SELECT "sentence"."id", "sentence"."name" COUNT(DISTINCT
> "token"."id") AS "n", T3."id" AS "n0", T4."id" AS "n1", T4."id" AS "n2",
> T6."id" AS "n3", T6."id" AS "n4" FROM "sentence" LEFT OUTER JOIN "token"
> ON ("sentence"."id" = "token"."sentence_id") INNER JOIN "token" T3 ON
> ("sentence"."id" = T3."sentence_id") INNER JOIN "token" T4 ON
> ("sentence"."id" = T4."sentence_id") INNER JOIN "token" T5 ON
> ("sentence"."id" = T5."sentence_id") INNER JOIN "token" T6 ON
> ("sentence"."id" = T6."sentence_id") INNER JOIN "token" T7 ON
> ("sentence"."id" = T7."sentence_id") WHERE (T3."name" IN (se) AND
> T4."name" IN (faire) AND T5."name" IN (un) AND T6."name" IN (avoir) AND
> T7."name" IN (faire)) GROUP BY "word_frword"."id", T3."id", T4."id",
> T6."id" HAVING COUNT(DISTINCT "token"."id") = 5
> }}}
>

> Why is numbering so strange (starts with `T3`)? But moreover why `n2` is
> assigned to `T4`, not `T5`? Same for `n4` and `T6`. Looks like numbers go
> by 2.
>
> What I want to accomplish is capture token id on each step of inner join.
> It works when there are one join, but then it breaks.
>
> Any suggestions?

New description:

 {{{
 class Sentence(Model):
 name = CharField()

 class Tokens(Model):
 token = CharField()
 sentence = ForeignKey(Sentence, related_name='tokens')
 }}}



 {{{
 Sentence.objects.annotate(n=Count('tokens',
 
distinct=True)).filter(n=5).filter(tokens__name__in=['se']).annotate(n0=F('tokens')).filter(tokens__name__in=['faire']).annotate(n1=F('tokens')).filter(tokens__name__in=['faire']).annotate(n2=F('tokens')).filter(tokens__name__in=['un']).annotate(n3=F('tokens')).filter(tokens__name__in=['avoir']).annotate(n4=F('tokens'))
 }}}


 Above code generates the following query:


 {{{
 SELECT "sentence"."id", "sentence"."name" COUNT(DISTINCT "token"."id")
 AS "n", T3."id" AS "n0", T4."id" AS "n1", T4."id" AS "n2", T6."id" AS
 "n3", T6."id" AS "n4" FROM "sentence" LEFT OUTER JOIN "token" ON
 ("sentence"."id" = "token"."sentence_id") INNER JOIN "token" T3 ON
 ("sentence"."id" = T3."sentence_id") INNER JOIN "token" T4 ON
 ("sentence"."id" = T4."sentence_id") INNER JOIN "token" T5 ON
 ("sentence"."id" = T5."sentence_id") INNER JOIN "token" T6 ON
 ("sentence"."id" = T6."sentence_id") INNER JOIN "token" T7 ON
 ("sentence"."id" = T7."sentence_id") WHERE (T3."name" IN (se) AND
 T4."name" IN (faire) AND T5."name" IN (un) AND T6."name" IN (avoir) AND
 T7."name" IN (faire)) GROUP BY "word_frword"."id", T3."id", T4."id",
 T6."id" HAVING COUNT(DISTINCT "token"."id") = 5
 }}}


 There is no `T4."id" AS "n2"` instead of `T5."id" AS "n2"`, so chaining is
 working incorrectly.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.43a5951bd5fd3e57a8f76a7bf504e7b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29015: Add an error when the PostgreSQL database name length limit is exceeded (was: Make Django aware of PostgreSQL database name length limits)

[Django]

#29015: Add an error when the PostgreSQL database name length limit is exceeded
-+-
 Reporter:  Tadej Janež  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => Database layer (models, ORM)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.db4738f326ba05d8a7c085b94edb826b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
 Reporter:  Paul |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  django-model,| Triage Stage:
  foreign-key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 This looks like an "is it a bug?" or "how do I do X?" question which
 should be asked on [wiki:TicketClosingReasons/UseSupportChannels our
 support channels] rather than in the bug tracker. If you can provide a
 more minimal query and explain why Django's behavior is incorrect, feel
 free to reopen.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.48eeeab13f2314266ac820a993b0b4a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29016: Reuse of UpdateQuery breaks some delete updates

[Django]

#29016: Reuse of UpdateQuery breaks some delete updates
-+-
 Reporter:  Étienne Loks |Owner:  Étienne
 |  Loks
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"419705bbe84e27c3d5be85f198a0352a6724927e" 419705bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="419705bbe84e27c3d5be85f198a0352a6724927e"
 [1.11.x] Fixed #29016 -- Fixed incorrect foreign key nullification on
 related instance deletion.

 Backport of 9a621edf624a4eb1f1645fca628a9e432f0de776 from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.ecf1a492186f6e7834264ed0765bdd29%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29016: Reuse of UpdateQuery breaks some delete updates

[Django]

#29016: Reuse of UpdateQuery breaks some delete updates
-+-
 Reporter:  Étienne Loks |Owner:  Étienne
 |  Loks
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"8f2e3857ce5a50839ee362690a6a6d92fc8ff0ea" 8f2e3857]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f2e3857ce5a50839ee362690a6a6d92fc8ff0ea"
 [2.0.x] Fixed #29016 -- Fixed incorrect foreign key nullification on
 related instance deletion.

 Backport of 9a621edf624a4eb1f1645fca628a9e432f0de776 from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.b1ee5321ddc81a8d4429f9aef5899ee0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29016: Reuse of UpdateQuery breaks some delete updates

[Django]

#29016: Reuse of UpdateQuery breaks some delete updates
-+-
 Reporter:  Étienne Loks |Owner:  Étienne
 |  Loks
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"9a621edf624a4eb1f1645fca628a9e432f0de776" 9a621edf]:
 {{{
 #!CommitTicketReference repository=""
 revision="9a621edf624a4eb1f1645fca628a9e432f0de776"
 Fixed #29016 -- Fixed incorrect foreign key nullification on related
 instance deletion.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.92a3399b210f74221b0f45a870ce250d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28643: Complete the ORM Function Library

[Django]

#28643: Complete the ORM Function Library
-+-
 Reporter:  Matthew Pava |Owner:  JunyiJ
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Thomas Lagae):

 When passing a non-numeric value into the {{{Abs}}} function, the
 behaviour differs between databases. I think this will also be the case
 for other math functions. Should we catch non-numeric values and throw an
 error or just document that this behaviour is undefined and differs
 between databases?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e42de2f74de0e7109563e6efda911ba4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29021: Weird behavior of foreign key lookup and annotate F expression

[Django]

#29021: Weird behavior of foreign key lookup and annotate F expression
-+-
   Reporter:  Paul   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|   Keywords:  django-model,
   Severity:  Normal |  foreign-key
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 {{{
 class Sentence(Model):
 name = CharField()

 class Tokens(Model):
 token = CharField()
 sentence = ForeignKey(Sentence, related_name='tokens')
 }}}



 {{{
 Sentence.objects.annotate(n=Count('tokens',
 
distinct=True)).filter(n=5).filter(tokens__name__in=['se']).annotate(n0=F('tokens')).filter(tokens__name__in=['faire']).annotate(n1=F('tokens')).filter(tokens__name__in=['faire']).annotate(n2=F('tokens')).filter(tokens__name__in=['un']).annotate(n3=F('tokens')).filter(tokens__name__in=['avoir']).annotate(n4=F('tokens'))
 }}}


 Above code generates the following query:


 {{{
 SELECT "sentence"."id", "sentence"."name" COUNT(DISTINCT "token"."id")
 AS "n", T3."id" AS "n0", T4."id" AS "n1", T4."id" AS "n2", T6."id" AS
 "n3", T6."id" AS "n4" FROM "sentence" LEFT OUTER JOIN "token" ON
 ("sentence"."id" = "token"."sentence_id") INNER JOIN "token" T3 ON
 ("sentence"."id" = T3."sentence_id") INNER JOIN "token" T4 ON
 ("sentence"."id" = T4."sentence_id") INNER JOIN "token" T5 ON
 ("sentence"."id" = T5."sentence_id") INNER JOIN "token" T6 ON
 ("sentence"."id" = T6."sentence_id") INNER JOIN "token" T7 ON
 ("sentence"."id" = T7."sentence_id") WHERE (T3."name" IN (se) AND
 T4."name" IN (faire) AND T5."name" IN (un) AND T6."name" IN (avoir) AND
 T7."name" IN (faire)) GROUP BY "word_frword"."id", T3."id", T4."id",
 T6."id" HAVING COUNT(DISTINCT "token"."id") = 5
 }}}


 Why is numbering so strange (starts with `T3`)? But moreover why `n2` is
 assigned to `T4`, not `T5`? Same for `n4` and `T6`. Looks like numbers go
 by 2.

 What I want to accomplish is capture token id on each step of inner join.
 It works when there are one join, but then it breaks.

 Any suggestions?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.09e3ba46e753294492b4bec0b7b5a7fb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28696: Add the ability to natively filter geometries by geom_type

[Django]

#28696: Add the ability to natively filter geometries by geom_type
+
 Reporter:  Geoffrey Fairchild  |Owner:  (none)
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Sergey Fedoseev):

 `GeometryType` works differently on PostGIS and SpatiaLite for 3d
 geometries, `SDO_GTYPE` returns integer, but not string.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9eec82003a1ced700fbf8166e1e3f378%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28696: Add the ability to natively filter geometries by geom_type

[Django]

#28696: Add the ability to natively filter geometries by geom_type
+
 Reporter:  Geoffrey Fairchild  |Owner:  (none)
 Type:  New feature |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Sergey Fedoseev):

 * owner:  Sergey Fedoseev => (none)
 * status:  assigned => new


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a2af9b629601093b9f79ecca553e16a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29016: Reuse of UpdateQuery breaks some delete updates

[Django]

#29016: Reuse of UpdateQuery breaks some delete updates
-+-
 Reporter:  Étienne Loks |Owner:  Étienne
 |  Loks
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good, I made some cosmetic edits and added release notes.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.ff517d576d2e2221381bd93ad48a6052%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29016: Reuse of UpdateQuery breaks some delete updates

[Django]

#29016: Reuse of UpdateQuery breaks some delete updates
-+-
 Reporter:  Étienne Loks |Owner:  Étienne
 |  Loks
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Étienne Loks):

 * owner:  nobody => Étienne Loks
 * status:  new => assigned


Comment:

 I have changed a model in `delete_regress` to add two foreign keys (it
 seems clearer to me). I have sent a pull request for the master branch.

 If it really qualifies to a backport (I agree with this qualification),
 how can I proceed to propose a patch? I miss a proper documentation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.86ad7fb0152b86c0369ad33821f9ee0a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.