Re: [Django] #30828: Document how to add ManyToMany relationships in bulk for different objects and for manually defined "through". (was: Add ManyToMany relationships in bulk)

[Django]

#30828: Document how to add ManyToMany relationships in bulk for different 
objects
and for manually defined "through".
-+-
 Reporter:  David Foster |Owner:  David
 Type:   |  Foster
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 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 felixxm):

 * type:  New feature => Cleanup/optimization
 * component:  Database layer (models, ORM) => Documentation


Comment:

 Let's change this to a documentation issue. I think we should add a
 paragraph about adding `ManyToManyField`'s relations with `bulk_create()`
 for manually defined `through` and for different objects (on LHS and RHS)
 to the "Insert in bulk" section (`docs/topics/db/optimization.txt`).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3dca936e7a61b97f0c947090281a555f%40djangoproject.com.

Re: [Django] #24810: Reopen database connection automatically when no transaction is active

[Django]

#24810: Reopen database connection automatically when no transaction is active
-+-
 Reporter:  Aymeric Augustin |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dms-cat):

 * cc: dms-cat (added)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a21ab0208ebc87d0949b1f80fa7205ae%40djangoproject.com.

Re: [Django] #30828: Add ManyToMany relationships in bulk

[Django]

#30828: Add ManyToMany relationships in bulk
-+-
 Reporter:  David Foster |Owner:  David
 |  Foster
 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 Simon Charette):

 > But you can't do some thing like adding the relations ... all at once.

 `.bulk_create(ignore_conflicts=True)`
 [https://github.com/django/django/pull/11899#pullrequestreview-301073824
 works reasonably well for this purpose] with a small boilerplate increase
 at the profit of readability. The latter also works for manually defined
 `through` with fields without defaults.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.226505f35cd7ef7674a469b4b3cdfa32%40djangoproject.com.

Re: [Django] #30842: Prefetch_related spends considerable time constructing querysets.

[Django]

#30842: Prefetch_related spends considerable time constructing querysets.
-+-
 Reporter:  Alex Aktsipetrov |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 I discovered that #20577 pushes for the same idea of deferring
 `_apply_related_filter` application. I think we should close this ticket
 as a duplicate and move the discussion there.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ea8716bd4f07d3bedc415f7f0d1dcd7c%40djangoproject.com.

Re: [Django] #30828: Add ManyToMany relationships in bulk

[Django]

#30828: Add ManyToMany relationships in bulk
-+-
 Reporter:  David Foster |Owner:  David
 |  Foster
 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 David Foster):

 Yes you can bulk add on a reverse relationship to associate many items
 with one other item in reverse. But you can't do some thing like adding
 the relations {(a1, b1), (a1, b2), (a2, b3), (a4, b4)} all at once.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.58dad17bf9684d691fe7d56e48990911%40djangoproject.com.

Re: [Django] #24042: Custom AutoField fields do not work correctly on postgres

[Django]

#24042: Custom AutoField fields do not work correctly on postgres
-+-
 Reporter:  Lucas Wiman  |Owner:  nobody
 Type:  New feature  |   Status:  new
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:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I think this ticket should probably be closed as ''fixed'' in the light of
 #27452 and support for the generic `db_returning` flag.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a27950217a27dc8fe685ccf99b35e595%40djangoproject.com.

Re: [Django] #26481: Add a "strict mode" for defer()/only() to prevent queries on unfetched field access

[Django]

#26481: Add a "strict mode" for defer()/only() to prevent queries on unfetched
field access
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  only, defer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 This has been implemented [https://github.com/charettes/django-seal as a
 third-party application].

 Not sure if this ticket should be closed as a duplicate of #22492 like
 #30874 was.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.46b67b7321f75c5631013d8308a38b93%40djangoproject.com.

Re: [Django] #28455: Create "inplace" QuerySets to speed up certain operations

[Django]

#28455: Create "inplace" QuerySets to speed up certain operations
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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 Simon Charette):

 * cc: Simon Charette (added)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bd7b88f16585d94b611805e1145d7812%40djangoproject.com.

Re: [Django] #22492: provide a way to prevent database queries on model objects

[Django]

#22492: provide a way to prevent database queries on model objects
-+-
 Reporter:  Chris Jerdonek   |Owner:  Raúl
 |  Cumplido
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  model,queryset,defer,only  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 #30874 was a duplicate.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8f275e70472b3ddcaee8f2180588c87d%40djangoproject.com.

Re: [Django] #30874: Allow disabling of lazy loading of model and related fields on querysets

[Django]

#30874: Allow disabling of lazy loading of model and related fields on querysets
---+--
 Reporter:  Rowan Seymour  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Simon Charette):

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


Comment:

 This is a duplicate of #22492.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.04e899ba987800b407a42079e09f7893%40djangoproject.com.

Re: [Django] #22492: provide a way to prevent database queries on model objects

[Django]

#22492: provide a way to prevent database queries on model objects
-+-
 Reporter:  Chris Jerdonek   |Owner:  Raúl
 |  Cumplido
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  model,queryset,defer,only  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 FWIW a third party application implements such queryset sealing
 capabilities.

 {{{#!python
 In [1]: from polls.models import Choice

 In [2]: p = Choice.objects.defer('body_yes').seal()

 In [3]: choice = p[0]

 In [4]: choice.body_yes

 Traceback (most recent call last):
   File "<>", line xxx, in 

 UnsealedAttributeAccess:: Attempt to fetch deferred field "body_yes" on
 sealed .
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f46b77c40dc8bcba1cf70015c6e0188a%40djangoproject.com.

Re: [Django] #30842: Prefetch_related spends considerable time constructing querysets.

[Django]

#30842: Prefetch_related spends considerable time constructing querysets.
-+-
 Reporter:  Alex Aktsipetrov |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alex Aktsipetrov):

 Replying to [comment:3 Simon Charette]:
 > Ideally only proxies to the original queryset would be created to defer
 the creation of querysets to only if needed.

 I think we can't really defer the creation, since such a proxy would have
 to share lots of features with the QuerySet?
 Although we probably can create a proxy to defer just filter calls.

 But instead I've tried fumbling with QuerySet itself, see the PR. That
 seems simpler from implementation perspective and also gives more control
 of copying.

 > I wonder if performing some form of local memoization per related
 manager class to call `manager._apply_rel_filters` only once manager type
 and using queryset cloning could speed up things a bit here. Happy to give
 it a broad try if that can get you started Alex.

 If you think this is a more promising approach, please do.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7e8f02ae95d0e110a7e4cc621acf6aef%40djangoproject.com.

Re: [Django] #30842: Prefetch_related spends considerable time constructing querysets.

[Django]

#30842: Prefetch_related spends considerable time constructing querysets.
-+-
 Reporter:  Alex Aktsipetrov |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex Aktsipetrov):

 * has_patch:  0 => 1


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0c6c8229f9c67309c9c27443618bae48%40djangoproject.com.

Re: [Django] #30879: Nested foreign key test failures in 3.0~beta1

[Django]

#30879: Nested foreign key test failures in 3.0~beta1
---+--
 Reporter:  Chris Lamb |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Simon Charette):

 I confirm that the issues are solved with the current SQLite master which
 is currently considered 3.31 probably by
 https://www.sqlite.org/src/info/aa57d7abac0bb92d.

 I'm not sure of what SQLite's backporting policy here though, is there's
 something we can do to get this in a possible 3.30.2 since it's a
 regression?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.356a91900e14e065020f0c8ac093c090%40djangoproject.com.

Re: [Django] #30879: Nested foreign key test failures in 3.0~beta1

[Django]

#30879: Nested foreign key test failures in 3.0~beta1
---+--
 Reporter:  Chris Lamb |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by felixxm):

 I've checked and they work fine with SQLite 3.29.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.d0bb1fd9afaec2876e39e21ee9728843%40djangoproject.com.

Re: [Django] #30881: Optimize _tx_resource_for_name() function in django/scripts/manage_translations.py

[Django]

#30881: Optimize  _tx_resource_for_name() function in
django/scripts/manage_translations.py
-+-
 Reporter:  ankit1219|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  Optimize scripts | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 Duplicate of #30880.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.6f1ddd967ac1391c079e1a767de61407%40djangoproject.com.

Re: [Django] #30879: Nested foreign key test failures in 3.0~beta1

[Django]

#30879: Nested foreign key test failures in 3.0~beta1
---+--
 Reporter:  Chris Lamb |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Chris Lamb):

 Indeed, I am using 3.30.1:

 {{{
 Setting up libsqlite3-0:amd64 (3.30.1-1) ...
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c891c61382cc259d0022ec3cfb5ba050%40djangoproject.com.

[Django] #30881: Optimize _tx_resource_for_name() function in django/scripts/manage_translations.py

[Django]

#30881: Optimize  _tx_resource_for_name() function in
django/scripts/manage_translations.py
-+-
   Reporter:  ankit1219  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  3.0
  (Other)|
   Severity:  Normal |   Keywords:  Optimize scripts
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 The **_tx_resource_for_name()** function in
 **django/scripts/manage_translations.py** uses simple if else statement to
 return the **Transifex resource name**.

 ''def _tx_resource_for_name(name):
 """ Return the Transifex resource name """
 if name == 'core':
 return "django.core"
 else:
 return "django.contrib-%s" % name''

 You can use Python ternary operator to  reduce code size and increase
 readability of the code.


 ''def _tx_resource_for_name(name):
 """ Return the Transifex resource name """
return "django.core" if name == 'core' else "django.contrib-%s" %
 name''

 It allows us to replace simple if statements with a single line
 expression. Increases code readability by reducing number of lines of
 code.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.fc727e6eeba0c685ecefcee276e03026%40djangoproject.com.

Re: [Django] #30879: Nested foreign key test failures in 3.0~beta1

[Django]

#30879: Nested foreign key test failures in 3.0~beta1
---+--
 Reporter:  Chris Lamb |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 I noticed these failures when running the suite against SQLite 3.30 and I
 think you ran the suite against SQLite 3.30.1 here.

 Given how long some of these tests have been around I suspect this is a
 regression in recent versions of SQLite.

 I'll try bisecting the exact version of SQLite that is causing issue here
 as I get similar failures on Django 2.1 and 2.2.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.de48aabb369aea7a3a9eb38fe62fe209%40djangoproject.com.

Re: [Django] #30880: Optimize the _tx_resource_for_name() function in django/scripts/manage_translations.py

[Django]

#30880: Optimize the _tx_resource_for_name() function in
django/scripts/manage_translations.py
-+-
 Reporter:  ankit1219|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Optimize scripts | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => wontfix


Comment:

 Decreasing the number of lines doesn't increase readability in most of
 cases. The current form looks good to me.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.aa7c3fee8a289a4cd876fe1777659498%40djangoproject.com.

Re: [Django] #30880: Optimize the _tx_resource_for_name() function in django/scripts/manage_translations.py

[Django]

#30880: Optimize the _tx_resource_for_name() function in
django/scripts/manage_translations.py
-+-
 Reporter:  ankit1219|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  Optimize scripts | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Old description:

> The **_tx_resource_for_name()** function in
> **django/scripts/manage_translations.py** uses simple if else statement
> to return the **Transifex resource name**.
>
> ''def _tx_resource_for_name(name):
> """ Return the Transifex resource name """
> if name == 'core':
> return "django.core"
> else:
> return "django.contrib-%s" % name''
>
> You can use Python ternary operator to  reduce code size and increase
> readability of the code.
>

> ''def _tx_resource_for_name(name):
> """ Return the Transifex resource name """
>return "django.core"   if name == 'core' else "django.contrib-%s"
> % name''
>
> It allows us to replace simple if statements with a single line
> expression. Increases code readability by reducing number of lines of
> code.

New description:

 The **_tx_resource_for_name()** function in
 **django/scripts/manage_translations.py** uses simple if else statement to
 return the **Transifex resource name**.

 def _tx_resource_for_name(name):
 if name == 'core':
 return "django.core"
 else:
 return "django.contrib-%s" % name

 You can use Python ternary operator to  reduce code size and increase
 readability of the code.


 def _tx_resource_for_name(name):
return "django.core"   if name == 'core' else "django.contrib-%s" %
 name

 It allows us to replace simple if statements with a single line
 expression. Increases code readability by reducing number of lines of
 code.

--

Comment (by ankit1219):

 I can send a PR to optimize the code.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.c662607566af9161fe3b8e7a51c3f523%40djangoproject.com.

[Django] #30880: Optimize the _tx_resource_for_name() function in django/scripts/manage_translations.py

[Django]

#30880: Optimize the _tx_resource_for_name() function in
django/scripts/manage_translations.py
-+-
   Reporter:  ankit1219  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  2.2
  (Other)|
   Severity:  Normal |   Keywords:  Optimize scripts
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 The **_tx_resource_for_name()** function in
 **django/scripts/manage_translations.py** uses simple if else statement to
 return the **Transifex resource name**.

 ''def _tx_resource_for_name(name):
 """ Return the Transifex resource name """
 if name == 'core':
 return "django.core"
 else:
 return "django.contrib-%s" % name''

 You can use Python ternary operator to  reduce code size and increase
 readability of the code.


 ''def _tx_resource_for_name(name):
 """ Return the Transifex resource name """
return "django.core"   if name == 'core' else "django.contrib-%s" %
 name''

 It allows us to replace simple if statements with a single line
 expression. Increases code readability by reducing number of lines of
 code.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.62e56a14381ab70e6276cfb55dc3e35e%40djangoproject.com.

[Django] #30879: Nested foreign key test failures in 3.0~beta1

[Django]

#30879: Nested foreign key test failures in 3.0~beta1
-+
   Reporter:  Chris Lamb |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 Hi,

 I am seeing the following test failures for the 3.0~beta1 release:

 {{{
 ==
 FAIL: test_explicit_ForeignKey
 (nested_foreign_keys.tests.DeeplyNestedForeignKeysTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.7/unittest/case.py", line 628, in run
 testMethod()
   File "/<>/tests/nested_foreign_keys/tests.py", line 176, in
 test_explicit_ForeignKey
 
self.assertEqual(Package.objects.exclude(screening__movie__director=self.director).count(),
 1)
   File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.7/unittest/case.py", line 845, in
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: 0 != 1

 ==
 FAIL: test_inheritance
 (nested_foreign_keys.tests.DeeplyNestedForeignKeysTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.7/unittest/case.py", line 628, in run
 testMethod()
   File "/<>/tests/nested_foreign_keys/tests.py", line 153, in
 test_inheritance
 
self.assertEqual(Event.objects.exclude(screening__movie__director=self.director).count(),
 1)
   File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.7/unittest/case.py", line 845, in
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: 0 != 1

 ==
 FAIL: test_explicit_ForeignKey
 (nested_foreign_keys.tests.NestedForeignKeysTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.7/unittest/case.py", line 628, in run
 testMethod()
   File "/<>/tests/nested_foreign_keys/tests.py", line 100, in
 test_explicit_ForeignKey
 self.assertEqual(Package.objects.exclude(screening__movie=self.movie).count(),
 1)
   File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.7/unittest/case.py", line 845, in
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: 0 != 1

 ==
 FAIL: test_explicit_ForeignKey_NullFK
 (nested_foreign_keys.tests.NestedForeignKeysTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.7/unittest/case.py", line 628, in run
 testMethod()
   File "/<>/tests/nested_foreign_keys/tests.py", line 121, in
 test_explicit_ForeignKey_NullFK
 
self.assertEqual(PackageNullFK.objects.exclude(screening__movie=self.movie).count(),
 2)
   File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.7/unittest/case.py", line 845, in
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: 1 != 2

 ==
 FAIL: test_inheritance (nested_foreign_keys.tests.NestedForeignKeysTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.7/unittest/case.py", line 628, in run
 testMethod()
   File "/<>/tests/nested_foreign_keys/tests.py", line 53, in
 test_inheritance
 self.assertEqual(Event.objects.exclude(screening__movie=self.movie).count(),
 1)
   File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.7/unittest/case.py", 

Re: [Django] #30828: Add ManyToMany relationships in bulk

[Django]

#30828: Add ManyToMany relationships in bulk
-+-
 Reporter:  David Foster |Owner:  David
 |  Foster
 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 felixxm):

 > However it's more difficult to associate many M1s with many M2s, ...

 You can use `set()` on a reverse relationship, e.g.
 {{{
 m2.m1_set.add(*m1s)
 }}}
 Right?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.193498ca2b57482c6a1cd9c334ccebbc%40djangoproject.com.

Re: [Django] #30252: ImageField's to_python() stores reference to closed Image object

[Django]

#30252: ImageField's to_python() stores reference to closed Image object
-+-
 Reporter:  Felix Dreissig   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.1
 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 Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned
 * has_patch:  0 => 1


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.80b6077b09d42091d86e7096f06b0df9%40djangoproject.com.

Re: [Django] #23941: Aggregating over decimal field regression

[Django]

#23941: Aggregating over decimal field regression
-+-
 Reporter:  Josh Smeaton |Owner:  Josh
 |  Smeaton
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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 Sardorbek Imomaliev):

 * cc: Sardorbek Imomaliev (added)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.f141386af1baed478436e97b4c30fbc7%40djangoproject.com.

Re: [Django] #30872: ManagementUtility.fetch_command prints "No Django settings specified." even if they are.

[Django]

#30872: ManagementUtility.fetch_command prints "No Django settings specified." 
even
if they are.
-+-
 Reporter:  Keryn Knight |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Keryn Knight):

 > This is also why we can't just check settings.configured, because
 that'll be False but not re-trigger the error.

 I think that's the crux of what I wasn't understanding. I'm guessing that
 always testing for settings.INSTALLED_APPS (ie: without being a in
 conditional branch) is some other use-case that won't work for all
 scenarios.

 > Then we have the (how common?) case of using settings.configure() with
 execute_from_command_line() and misspelling a command (despite
 autocomplete()) and then getting a slightly misleading message [...]

 Yeah, I fully appreciate that it's an edge-case, and I'm certainly not
 going to push hard on it being done (it's been there for however many
 years already), and you **definitely** don't need to commit to a specific
 day(!) on which to do it, but it would seem that what you've proposed
 would quash my quibble :) [minor aside: I'd wager the usage of
 autocomplete is also vanishingly small, given it requires additional
 steps]

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.143856ca2fd1aadbd8b8e030c8d99dd1%40djangoproject.com.

Re: [Django] #30878: Django catched a request error when deploy nameserver to IP. (was: django catch request error when deploy nameserver to ip)

[Django]

#30878: Django catched a request error when deploy nameserver to IP.
---+--
 Reporter:  liumilan   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ecc9272a2b1c4d725f92a867c2147083%40djangoproject.com.

Re: [Django] #30878: django catch request error when deploy nameserver to ip

[Django]

#30878: django catch request error when deploy nameserver to ip
---+--
 Reporter:  liumilan   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by felixxm):

 * status:  new => closed
 * component:  Uncategorized => Utilities
 * version:  2.2 => master
 * type:  Uncategorized => Bug
 * resolution:   => invalid


Comment:

 It is an issue related with sockets maybe antivirus or firewall blocks
 connections, it is hard to tell. Please don't use trac as a support
 channel.

 Closing per TicketClosingReasons/UseSupportChannels.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.959d9510c60abba315447994ba1f719b%40djangoproject.com.

Re: [Django] #26207: Replace dynamic classes with non-data descriptors for deferred instance loading

[Django]

#26207: Replace dynamic classes with non-data descriptors for deferred instance
loading
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"8d196e6feaeef38dc7b698c26de5fe2317349fe3" 8d196e6f]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d196e6feaeef38dc7b698c26de5fe2317349fe3"
 [3.0.x] Refs #26207 -- Removed obsolete note about slow constructing a
 model with deferred fields.

 This is not true since 7f51876 removed the necessity of creating
 proxy model classes at runtime for each deferred field sets.
 Backport of 35396a7f243eceec42cc90725ab573a7d9ac3b4c 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0ca7a29955a70d88e7054544c16c5ced%40djangoproject.com.

Re: [Django] #26207: Replace dynamic classes with non-data descriptors for deferred instance loading

[Django]

#26207: Replace dynamic classes with non-data descriptors for deferred instance
loading
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"f037ae11ec97f90ff94fbff2cdae336619ae63c5" f037ae11]:
 {{{
 #!CommitTicketReference repository=""
 revision="f037ae11ec97f90ff94fbff2cdae336619ae63c5"
 [2.2.x] Refs #26207 -- Removed obsolete note about slow constructing a
 model with deferred fields.

 This is not true since 7f51876 removed the necessity of creating
 proxy model classes at runtime for each deferred field sets.
 Backport of 35396a7f243eceec42cc90725ab573a7d9ac3b4c 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.87305492ecd448c7c72dd3d771bfa999%40djangoproject.com.

Re: [Django] #26207: Replace dynamic classes with non-data descriptors for deferred instance loading

[Django]

#26207: Replace dynamic classes with non-data descriptors for deferred instance
loading
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"35396a7f243eceec42cc90725ab573a7d9ac3b4c" 35396a7f]:
 {{{
 #!CommitTicketReference repository=""
 revision="35396a7f243eceec42cc90725ab573a7d9ac3b4c"
 Refs #26207 -- Removed obsolete note about slow constructing a model with
 deferred fields.

 This is not true since 7f51876 removed the necessity of creating
 proxy model classes at runtime for each deferred field sets.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8a9b68d41b34b201d5f6429d5e0bd1b8%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d2f02aa56b57f8b3de1b624f8b1a909c67b6823a" d2f02aa5]:
 {{{
 #!CommitTicketReference repository=""
 revision="d2f02aa56b57f8b3de1b624f8b1a909c67b6823a"
 [2.2.x] Fixed #30870 -- Fixed showing that RunPython operations are
 irreversible by migrate --plan.

 Thanks Hasan Ramezani for the initial patch and Kyle Dickerson for the
 report.

 Backport of 06d34aab7cfb1632a1538a243db81f24498525ff 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1321e09591a2dfc8aff9a73c8a7b5bc1%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"4a756cbc383bdefb683f03a0d40c0d0630ba3f60" 4a756cb]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a756cbc383bdefb683f03a0d40c0d0630ba3f60"
 [3.0.x] Fixed #30870 -- Fixed showing that RunPython operations are
 irreversible by migrate --plan.

 Thanks Hasan Ramezani for the initial patch and Kyle Dickerson for the
 report.

 Backport of 06d34aab7cfb1632a1538a243db81f24498525ff 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.61786545cc0e51c3f8f4e6a108b81a12%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"06d34aab7cfb1632a1538a243db81f24498525ff" 06d34aab]:
 {{{
 #!CommitTicketReference repository=""
 revision="06d34aab7cfb1632a1538a243db81f24498525ff"
 Fixed #30870 -- Fixed showing that RunPython operations are irreversible
 by migrate --plan.

 Thanks Hasan Ramezani for the initial patch and Kyle Dickerson for the
 report.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8d62bec72dcbcb3c4b88d809368dd39c%40djangoproject.com.

Re: [Django] #30876: Move `django.utils.decorators.classproperty` to `django.utils.functional`. (was: Move `django.utils.decorators.classproperty` to `django.utils.functional`)

[Django]

#30876: Move `django.utils.decorators.classproperty` to 
`django.utils.functional`.
---+-
 Reporter:  André Ericson  |Owner:  André Ericson
 Type:  New feature|   Status:  assigned
Component:  Utilities  |  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 felixxm):

 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => Utilities


Comment:

 This is an undocumented decorator so I don't think that we need to
 deprecate it. Release note in "Backwards incompatible changes" should be
 enough.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.524fcaf02138eb4da796333f128ade09%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * easy:  1 => 0
 * needs_docs:  1 => 0


Comment:

 [https://github.com/django/django/pull/11911 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.df8efec671a5405416bc125abf5a1be5%40djangoproject.com.

[Django] #30878: django catch request error when deploy nameserver to ip

[Django]

#30878: django catch request error when deploy nameserver to ip
-+
   Reporter:  liumilan   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.2
   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  |
-+
 When I deploy the nameserver to the IP host, django will catch the error
 request from the nameserver. Maybe the nameserver sent a hearbeat to the
 IP host. How can I disable this error log from django?
  Exception happened during processing of request from ('127.0.0.1', 51975)
 Traceback (most recent call last):
   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line 654,
 in process_request_thread
 self.finish_request(request, client_address)
   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line 364,
 in finish_request
 self.RequestHandlerClass(request, client_address, self)
   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line 724,
 in __init__
 self.handle()
   File "/data/home/anaconda3/lib/python3.6/site-
 packages/django/core/servers/basehttp.py", line 169, in handle
 self.handle_one_request()
   File "/data/home/anaconda3/lib/python3.6/site-
 packages/django/core/servers/basehttp.py", line 179, in handle_one_request
 self.raw_requestline = self.rfile.readline(65537)
   File "/data/home/anaconda3/lib/python3.6/socket.py", line 586, in
 readinto
 return self._sock.recv_into(b)
 ConnectionResetError: [Errno 104] Connection reset by peer

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.a11c006335ab3da6130cd3791e8a3277%40djangoproject.com.

Re: [Django] #30878: django catch request error when deploy nameserver to ip

[Django]

#30878: django catch request error when deploy nameserver to ip
---+--
 Reporter:  liumilan   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by liumilan:

Old description:

> When I deploy the nameserver to the IP host, django will catch the error
> request from the nameserver. Maybe the nameserver sent a hearbeat to the
> IP host. How can I disable this error log from django?
>  Exception happened during processing of request from ('127.0.0.1',
> 51975)
> Traceback (most recent call last):
>   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line
> 654, in process_request_thread
> self.finish_request(request, client_address)
>   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line
> 364, in finish_request
> self.RequestHandlerClass(request, client_address, self)
>   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line
> 724, in __init__
> self.handle()
>   File "/data/home/anaconda3/lib/python3.6/site-
> packages/django/core/servers/basehttp.py", line 169, in handle
> self.handle_one_request()
>   File "/data/home/anaconda3/lib/python3.6/site-
> packages/django/core/servers/basehttp.py", line 179, in
> handle_one_request
> self.raw_requestline = self.rfile.readline(65537)
>   File "/data/home/anaconda3/lib/python3.6/socket.py", line 586, in
> readinto
> return self._sock.recv_into(b)
> ConnectionResetError: [Errno 104] Connection reset by peer

New description:

 When I deploy the nameserver to the IP host, django will catch the error
 request from the nameserver. Maybe the nameserver sent a hearbeat to the
 IP host. How can I disable this error log from django?

 {{{
 Exception happened during processing of request from ('127.0.0.1', 51975)
 Traceback (most recent call last):
   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line 654,
 in process_request_thread
 self.finish_request(request, client_address)
   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line 364,
 in finish_request
 self.RequestHandlerClass(request, client_address, self)
   File "/data/home/anaconda3/lib/python3.6/socketserver.py", line 724,
 in __init__
 self.handle()
   File "/data/home/anaconda3/lib/python3.6/site-
 packages/django/core/servers/basehttp.py", line 169, in handle
 self.handle_one_request()
   File "/data/home/anaconda3/lib/python3.6/site-
 packages/django/core/servers/basehttp.py", line 179, in handle_one_request
 self.raw_requestline = self.rfile.readline(65537)
   File "/data/home/anaconda3/lib/python3.6/socket.py", line 586, in
 readinto
 return self._sock.recv_into(b)
 ConnectionResetError: [Errno 104] Connection reset by peer
 }}}

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8da166721a4db13e641673d7ce6f789d%40djangoproject.com.

Re: [Django] #30877: User Password Automatically changes after 15 days. (was: User Password Automatically changes after 15 days)

[Django]

#30877: User Password Automatically changes after 15 days.
-+-
 Reporter:  abhisek11|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  django auth problem  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * type:  Uncategorized => Bug
 * resolution:   => invalid


Comment:

 Django doesn't change passwords automatically. Please don't use trac as a
 support channel.

 Closing per TicketClosingReasons/UseSupportChannels.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b00c78d5ff30ff884ccc1a86203b3d3f%40djangoproject.com.

[Django] #30877: User Password Automatically changes after 15 days

[Django]

#30877: User Password Automatically changes after 15 days
-+-
   Reporter:  abhisek11  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.2
  contrib.auth   |
   Severity:  Normal |   Keywords:  django auth problem
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am facing a serious  issue in production, that password of users table
 is automatically changes after 15 days or probably 2 weeks
 we are using
 server:- AWS server EC2  instance
 database:- MYSql
 Usertable :- Django auth table

 please look into this on priority

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.ae0c19a18107cf5ae8b0a2b94eda137a%40djangoproject.com.

Re: [Django] #25817: Unable to rename a field reference in foreign key 'to_field'

[Django]

#25817: Unable to rename a field reference in foreign key 'to_field'
-+-
 Reporter:  Simon Kelly  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  to_field rename  | 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 Mariusz Felisiak ):

 In [changeset:"2839659b42ef80038152768b6cedae1016c59d90" 2839659b]:
 {{{
 #!CommitTicketReference repository=""
 revision="2839659b42ef80038152768b6cedae1016c59d90"
 Fixed #30868 -- Prevented unnecessary AlterField when renaming a
 referenced pk.

 Regression introduced by dcdd219ee1, refs #25817.

 Thanks Carlos E. C. Leite for the report and Mariusz for the bisect.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8b7f58b8abae0dd3aa908fb217e0353e%40djangoproject.com.

Re: [Django] #25817: Unable to rename a field reference in foreign key 'to_field'

[Django]

#25817: Unable to rename a field reference in foreign key 'to_field'
-+-
 Reporter:  Simon Kelly  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  to_field rename  | 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 Mariusz Felisiak ):

 In [changeset:"bab3ad54ff30848a16f08d72e70d8edbab019a63" bab3ad5]:
 {{{
 #!CommitTicketReference repository=""
 revision="bab3ad54ff30848a16f08d72e70d8edbab019a63"
 [3.0.x] Fixed #30868 -- Prevented unnecessary AlterField when renaming a
 referenced pk.

 Regression introduced by dcdd219ee1, refs #25817.

 Thanks Carlos E. C. Leite for the report and Mariusz for the bisect.

 Backport of 2839659b42ef80038152768b6cedae1016c59d90 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.03f76f84df3c03a2738b3fc433a3f65a%40djangoproject.com.

Re: [Django] #30868: ForeignKey's to_field parameter gets the old field's name when renaming a PrimaryKey.

[Django]

#30868: ForeignKey's to_field parameter gets the old field's name when renaming 
a
PrimaryKey.
-+-
 Reporter:  Carlos E. C. Leite   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migration| Triage Stage:  Accepted
  renamefield to_field   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"2839659b42ef80038152768b6cedae1016c59d90" 2839659b]:
 {{{
 #!CommitTicketReference repository=""
 revision="2839659b42ef80038152768b6cedae1016c59d90"
 Fixed #30868 -- Prevented unnecessary AlterField when renaming a
 referenced pk.

 Regression introduced by dcdd219ee1, refs #25817.

 Thanks Carlos E. C. Leite for the report and Mariusz for the bisect.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.956b1357d34062bebd386bae1cad6d0f%40djangoproject.com.

Re: [Django] #30868: ForeignKey's to_field parameter gets the old field's name when renaming a PrimaryKey.

[Django]

#30868: ForeignKey's to_field parameter gets the old field's name when renaming 
a
PrimaryKey.
-+-
 Reporter:  Carlos E. C. Leite   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migration| Triage Stage:  Accepted
  renamefield to_field   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"bab3ad54ff30848a16f08d72e70d8edbab019a63" bab3ad5]:
 {{{
 #!CommitTicketReference repository=""
 revision="bab3ad54ff30848a16f08d72e70d8edbab019a63"
 [3.0.x] Fixed #30868 -- Prevented unnecessary AlterField when renaming a
 referenced pk.

 Regression introduced by dcdd219ee1, refs #25817.

 Thanks Carlos E. C. Leite for the report and Mariusz for the bisect.

 Backport of 2839659b42ef80038152768b6cedae1016c59d90 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.d1d7e7810059dacac17424304dde4778%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by felixxm):

 Replying to [comment:6 Kyle Dickerson]:
 > The current code ''should'' have that behavior because, with this bug
 fix, `action` should only be `None` on line 356 if we set it based on
 either `reverse_code` or `reverse_sql` (since `code` and `sql` are
 required attributes of their respective operations), but it's not an
 explicit restriction in the current form.  It would certainly be more
 readable to make that restriction explicit (e.g., in my proposed broader
 refactor).

 `code` and `sql` are required attributes but they can be empty,
 nevertheless I agree that `IRREVERSIBLE` should be displayed on for
 `backwards`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.396e687c84725ab456879db23a03ba71%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by felixxm):

 This is a release blocker so it's quite urgent, I'm going to work on it
 now, and prepare Django 3.0b1 after 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.90ef8e555dc6221ed2c8103845d2954d%40djangoproject.com.

Re: [Django] #30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without docstrings.

[Django]

#30870: "migrate --plan" outputs "IRREVERSIBLE" on RunPython operations without
docstrings.
-+-
 Reporter:  Kyle Dickerson   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Hasan Ramezani):

 The patch is ready. I am going to clean it and add test for it. I can push
 it today.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.762a80e111d223198c1bc51e59b47928%40djangoproject.com.