Re: [Django] #26891: ForeignObject/ForeignKey does not obey lookup registration API

[Django]

#26891: ForeignObject/ForeignKey does not obey lookup registration API
-+-
 Reporter:  Ryan P Kilby |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (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 Carlton Gibson ):

 In [changeset:"a004350193a503b6722633c4309f70551fde0983" a0043501]:
 {{{
 #!CommitTicketReference repository=""
 revision="a004350193a503b6722633c4309f70551fde0983"
 [2.1.x] Refs #29593, #26891 -- Doc'd RegisterLookupMixin.get_lookups().

 Backport of a67ebcb1cbd37e1fc9eddd2da1dda7f319c5ac1d 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/065.42a06e8e8dcfade8b7c5496ef414d04a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page

[Django]

#29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page
-+-
 Reporter:  Ryan Verner  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Release blocker  |   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 Carlton Gibson ):

 In [changeset:"a004350193a503b6722633c4309f70551fde0983" a0043501]:
 {{{
 #!CommitTicketReference repository=""
 revision="a004350193a503b6722633c4309f70551fde0983"
 [2.1.x] Refs #29593, #26891 -- Doc'd RegisterLookupMixin.get_lookups().

 Backport of a67ebcb1cbd37e1fc9eddd2da1dda7f319c5ac1d 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/062.b46a3f4cb68727b5d4c9d8fe7e7156f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29631: Feature Request: models.UniqueBooleanField()

[Django]

#29631: Feature Request: models.UniqueBooleanField()
-+-
   Reporter:  Michael|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  2.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Imagine the schema for a tweet on Twitter:

 {{{
 class Tweet(models.Model):
content = models.Charfield(max_length=280)
user = models.ForeignKey(User)
pinned = models.UniqueBooleanField(default=False, unique_with='user')
 }}}

 The user pins a tweet and behind the scenes `UniqueBooleanField` would set
 the previous tweet's pinned field to False (if any) and set the current
 one to True. This has tons of other use cases, including: the default
 group for a user and anything where there can only be one "default" given
 a `unique_with` property.

 Is this a dumb idea? Is there already a better, more Django-idiomatic way?
 All feedback is appreciated.

 Thanks,

 Michael

-- 
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/050.430ea88a532187cd34a2d9ac6dcdbef0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27753: Cleanups when no supported version of Django supports Python 2 anymore

[Django]

#27753: Cleanups when no supported version of Django supports Python 2 anymore
-+-
 Reporter:  Aymeric Augustin |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I just wanted to mention that in my opinion it would make more sense for
 `SafeText` to go away instead of `SafeString` to be consistent with the
 `(smart|force)_text` removal.

 Given we're currently publicly documenting that `SafeText` is an alias for
 `SafeString` we should adjust the code and documentation for it to be
 other way around instead before we move forward with the `SafeText`
 removal or deprecation.

-- 
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.f1329fbd9a685cad5ee124b23876fd2c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29627: QueryDict.urlencode() crashes on non-string values

[Django]

#29627: QueryDict.urlencode() crashes on non-string values
-+
 Reporter:  Rafał P. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  2.1
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"0cfca0f2ccc2050de9de65a28d241d8cafcfe666" 0cfca0f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="0cfca0f2ccc2050de9de65a28d241d8cafcfe666"
 [2.1.x] Fixed #29627 -- Fixed QueryDict.urlencode() crash with non-string
 values.

 Regression in 7d96f0c49ab750799860e42716d7105e11de44de.
 Backport of d8e2be459f97f1773c7edf7d37de180139146176 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/065.93f6f9547f6754704f7121109bf568a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29627: QueryDict.urlencode() crashes on non-string values

[Django]

#29627: QueryDict.urlencode() crashes on non-string values
-+
 Reporter:  Rafał P. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  2.1
 Severity:  Release blocker  |   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 GitHub ):

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


Comment:

 In [changeset:"d8e2be459f97f1773c7edf7d37de180139146176" d8e2be45]:
 {{{
 #!CommitTicketReference repository=""
 revision="d8e2be459f97f1773c7edf7d37de180139146176"
 Fixed #29627 -- Fixed QueryDict.urlencode() crash with non-string values.

 Regression in 7d96f0c49ab750799860e42716d7105e11de44de.
 }}}

-- 
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/065.772ea243c636a83ce6efe5f632835f81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29629: Remove (deprecate?) django.utils.six

[Django]

#29629: Remove (deprecate?) django.utils.six
-+-
 Reporter:  Josh Schneier|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.1
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Duplicate of #27753.

-- 
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.9dfcd011847d2623ca6184922e633781%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

[Django]

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  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:   => needsinfo


Comment:

 Hey there,

 Without details about the query that's causing the crash for volunteers to
 determine whether or not the issue is in with project or caused by Django
 2.1 itself.

 If the debugging page doesn't expose the problematic query you can turn
 query logging to the `runserver` console with the following `LOGGING`
 tweak

 {{{#!python
 LOGGING['loggers']['django.db.backends'] = {
 'level': 'DEBUG',
 'handlers': ['console'],
 }
 }}}

 Please re-open if you can provide details proving that Django is at fault.

-- 
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.835a49deba4262b6dc2d8d20a5d70d14%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page

[Django]

#29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page
-+-
 Reporter:  Ryan Verner  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Release blocker  |   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 Simon Charette):

 Ryan, it should eventually show up. I just did the backport to the
 `stable/2.1.x` branch.

-- 
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/062.c65308dc647e1ace3f10af52cb40bf05%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page

[Django]

#29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page
-+-
 Reporter:  Ryan Verner  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Release blocker  |   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 Simon Charette ):

 In [changeset:"66c0c58cf2bc08233ca7bd1d4973e34cbc2ab2ec" 66c0c58c]:
 {{{
 #!CommitTicketReference repository=""
 revision="66c0c58cf2bc08233ca7bd1d4973e34cbc2ab2ec"
 [2.1.x] Fixed #29593 -- Added QUERY_TERMS removal to 2.1 release notes.

 Removed in 244cc401559e924355cf943b6b8e66ccf2f6da3a.

 Backport of 5180015051f262b73559bb55a8e3fe6f551f8b68 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/062.f8c7ff69c157c530ac496c1cd43f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

[Django]

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by zelfor5436:

Old description:

> Attempting to log in to the admin interface causes a SQL exception to be
> raised when using an Oracle database. The exception throw by Oracle is
> ... ORA-00918: column ambiguously defined.
>
> Database: Oracle 12.1
> cx_Oracle version: 6.4.1
>
> Steps to reproduce...
>
> 1) Start a project
> 2) Execute makemigrations
> 3) Execute migrate
> 4) Execute createsuperuser
> 5) Execute runserver
> 6) Open localhost:8000/admin in a browser
> 7) Enter admin username/password and click to log in
>
> At this point, Django will respond with an exception page indicating that
> Oracle has raised a SQL exception. Rolling back to Django 2.0.7
> eliminates the problem and the admin interface behaves as expected.
>
> It looks like the cause is related to base.html used in the admin
> templates. I'm assuming the problem is either related to some kind of
> change, since 2.0.7, in how SQL is constructed, or changes/additions in
> what kind of statements are being emitted by the templates for the admin
> interface.
>
> I'll try to dig into this further on Monday when I return to work.
> Relatively new to Django, so I'm not as familiar as I'd like to be with
> what's going on under the hood and I'm not sure where to really begin
> digging in as this deals with things that come prepackaged with the
> framework.

New description:

 Attempting to log in to the admin interface causes a SQL exception to be
 raised when using an Oracle database. The exception throw by Oracle is ...
 ORA-00918: column ambiguously defined.

 Database: Oracle 12.1
 cx_Oracle version: 6.4.1

 Steps to reproduce...

 1) Start a project
 2) Configure the use of Oracle as a database
 3) Execute makemigrations
 4) Execute migrate
 5) Execute createsuperuser
 6) Execute runserver
 7) Open localhost:8000/admin in a browser
 8) Enter admin username/password and click to log in

 At this point, Django will respond with an exception page indicating that
 Oracle has raised a SQL exception. Rolling back to Django 2.0.7 eliminates
 the problem and the admin interface behaves as expected.

 It looks like the cause is related to base.html used in the admin
 templates. I'm assuming the problem is either related to some kind of
 change, since 2.0.7, in how SQL is constructed, or changes/additions in
 what kind of statements are being emitted by the templates for the admin
 interface.

 Interestingly enough, there's no problem when using a SQLite database.

 I'll try to dig into this further on Monday when I return to work.
 Relatively new to Django, so I'm not as familiar as I'd like to be with
 what's going on under the hood and I'm not sure where to really begin
 digging in as this deals with things that come prepackaged with the
 framework.

--

-- 
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.cb953abbb7da58c3c333550e48ebd615%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

[Django]

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by zelfor5436:

Old description:

> Attempting to log in to the admin interface causes a SQL exception to be
> raised when using an Oracle database. The exception throw by Oracle is
> ... ORA-00918: column ambiguously defined.
>
> Database: Oracle 12.1
> cx_Oracle version: 6.4.1
>
> Steps to reproduce...
>
> 1) Start a project
> 2) Execute makemigrations
> 3) Execute migrate
> 4) Execute createsuperuser
> 5) Execute runserver
> 6) Open localhost:8000/admin in a browser
> 7) Enter admin username/password and click to log in
>
> At this point, Django will respond with an exception page indicating that
> Oracle has raised a SQL exception. Rolling back to Django 2.0.7
> eliminates the problem and the admin interface behaves as expected.
>
> It looks like the cause is related to base.html used in the admin
> templates. I'm assuming the problem is either related to some kind of
> change, since 2.0.7, in how SQL is constructed, or changes/additions in
> what kind of statements are being emitted by the templates for the admin
> interface.

New description:

 Attempting to log in to the admin interface causes a SQL exception to be
 raised when using an Oracle database. The exception throw by Oracle is ...
 ORA-00918: column ambiguously defined.

 Database: Oracle 12.1
 cx_Oracle version: 6.4.1

 Steps to reproduce...

 1) Start a project
 2) Execute makemigrations
 3) Execute migrate
 4) Execute createsuperuser
 5) Execute runserver
 6) Open localhost:8000/admin in a browser
 7) Enter admin username/password and click to log in

 At this point, Django will respond with an exception page indicating that
 Oracle has raised a SQL exception. Rolling back to Django 2.0.7 eliminates
 the problem and the admin interface behaves as expected.

 It looks like the cause is related to base.html used in the admin
 templates. I'm assuming the problem is either related to some kind of
 change, since 2.0.7, in how SQL is constructed, or changes/additions in
 what kind of statements are being emitted by the templates for the admin
 interface.

 I'll try to dig into this further on Monday when I return to work.
 Relatively new to Django, so I'm not as familiar as I'd like to be with
 what's going on under the hood and I'm not sure where to really begin
 digging in as this deals with things that come prepackaged with the
 framework.

--

-- 
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.c33da7a4f9d5f19c8e4401e9c40fea9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

[Django]

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
   Reporter: |  Owner:  nobody
  zelfor5436 |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.1
  Uncategorized  |   Keywords:  oracle, admin,
   Severity:  Normal |  exception
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Attempting to log in to the admin interface causes a SQL exception to be
 raised when using an Oracle database. The exception throw by Oracle is ...
 ORA-00918: column ambiguously defined.

 Database: Oracle 12.1
 cx_Oracle version: 6.4.1

 Steps to reproduce...

 1) Start a project
 2) Execute makemigrations
 3) Execute migrate
 4) Execute createsuperuser
 5) Execute runserver
 6) Open localhost:8000/admin in a browser
 7) Enter admin username/password and click to log in

 At this point, Django will respond with an exception page indicating that
 Oracle has raised a SQL exception. Rolling back to Django 2.0.7 eliminates
 the problem and the admin interface behaves as expected.

 It looks like the cause is related to base.html used in the admin
 templates. I'm assuming the problem is either related to some kind of
 change, since 2.0.7, in how SQL is constructed, or changes/additions in
 what kind of statements are being emitted by the templates for the admin
 interface.

-- 
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/053.9cfe5f0e9f7cfeb616a6668a2ec18c5d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page

[Django]

#29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page
-+-
 Reporter:  Ryan Verner  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Release blocker  |   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 Ryan Verner):

 Hey, did this not make it into the official documentation?  I assumed that
 would be automatically generated from the repo.

 This isn't mentioned on this page, which is where people will generally be
 looking for upgrade/depreciation advice -
 https://docs.djangoproject.com/en/2.1/releases/2.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 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/062.5f6e5921df46ba5867fdbd26b9f0dd05%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29629: Remove (deprecate?) django.utils.six

[Django]

#29629: Remove (deprecate?) django.utils.six
+
   Reporter:  Josh Schneier |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Utilities |Version:  2.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 We no longer support Python 2 so might as well slim down the codebase. The
 only remaining use of six is to export `python_2_unicode_compatible` which
 can be removed (or deprecated? not clear on policy) as well.

-- 
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/052.d8ed4c85ce544c467d77cc83d3640a71%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29627: QueryDict.urlencode() crashes on non-string values

[Django]

#29627: QueryDict.urlencode() crashes on non-string values
-+
 Reporter:  Rafał P. |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  2.1
 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 Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10263 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/065.524663512076c3cecaac3d8c79d25d6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29616: Do not ask password in createsuperuser command if used custom user model without password field

[Django]

#29616: Do not ask password in createsuperuser command if used custom user model
without password field
-+-
 Reporter:  Semyon Pupkov|Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  users| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Schneier):

 * status:  new => assigned
 * owner:  nobody => Josh Schneier


-- 
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.8bf1f5e7d72e24bb476580cacfbb9438%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29613: Allow --keepdb to work on PostgreSQL if the database exists but the user can't create databases

[Django]

#29613: Allow --keepdb to work on PostgreSQL if the database exists but the user
can't create databases
-+-
 Reporter:  Paul McDermott   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, --keepdb   | 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


-- 
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/069.a868a51998f20049aa426108090f0fe9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29499: Race condition in QuerySet.update_or_create()

[Django]

#29499: Race condition in QuerySet.update_or_create()
-+-
 Reporter:  Michael Sanders  |Owner:  Michael
 |  Sanders
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  race-condition   | 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:"2668418d99b42599536d353705456cf5db718d48" 2668418d]:
 {{{
 #!CommitTicketReference repository=""
 revision="2668418d99b42599536d353705456cf5db718d48"
 [1.11.x] Fixed #29499 -- Fixed race condition in
 QuerySet.update_or_create().

 A race condition happened when the object didn't already exist and
 another process/thread created the object before update_or_create()
 did and then attempted to update the object, also before
 update_or_create()
 saved the object. The update by the other process/thread could be lost.

 Backport of 271542dad1686c438f658aa6220982495db09797 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.b8c8df0088cc920462d45297c8965d83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29499: Race condition in QuerySet.update_or_create()

[Django]

#29499: Race condition in QuerySet.update_or_create()
-+-
 Reporter:  Michael Sanders  |Owner:  Michael
 |  Sanders
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  race-condition   | 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:"271542dad1686c438f658aa6220982495db09797" 271542da]:
 {{{
 #!CommitTicketReference repository=""
 revision="271542dad1686c438f658aa6220982495db09797"
 Fixed #29499 -- Fixed race condition in QuerySet.update_or_create().

 A race condition happened when the object didn't already exist and
 another process/thread created the object before update_or_create()
 did and then attempted to update the object, also before
 update_or_create()
 saved the object. The update by the other process/thread could be lost.
 }}}

-- 
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.c31c48916e20a4749df8dacb5c9ddbd5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29499: Race condition in QuerySet.update_or_create()

[Django]

#29499: Race condition in QuerySet.update_or_create()
-+-
 Reporter:  Michael Sanders  |Owner:  Michael
 |  Sanders
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  race-condition   | 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:"221ef69a9b89262456bb7abe0e5a4b2fda4a0695" 221ef69a]:
 {{{
 #!CommitTicketReference repository=""
 revision="221ef69a9b89262456bb7abe0e5a4b2fda4a0695"
 [2.1.x] Fixed #29499 -- Fixed race condition in
 QuerySet.update_or_create().

 A race condition happened when the object didn't already exist and
 another process/thread created the object before update_or_create()
 did and then attempted to update the object, also before
 update_or_create()
 saved the object. The update by the other process/thread could be lost.

 Backport of 271542dad1686c438f658aa6220982495db09797 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.825f138b5d26106c459c967d60784747%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29499: Race condition in QuerySet.update_or_create()

[Django]

#29499: Race condition in QuerySet.update_or_create()
-+-
 Reporter:  Michael Sanders  |Owner:  Michael
 |  Sanders
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  race-condition   | 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:"4441826026c888a479d5262d47fbbd72a689efa8" 44418260]:
 {{{
 #!CommitTicketReference repository=""
 revision="4441826026c888a479d5262d47fbbd72a689efa8"
 [2.0.x] Fixed #29499 -- Fixed race condition in
 QuerySet.update_or_create().

 A race condition happened when the object didn't already exist and
 another process/thread created the object before update_or_create()
 did and then attempted to update the object, also before
 update_or_create()
 saved the object. The update by the other process/thread could be lost.

 Backport of 271542dad1686c438f658aa6220982495db09797 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.7bc2eacaa6bd0114154aea42f519a56f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29628: createsuperuser does not validate password against username or other required fields

[Django]

#29628: createsuperuser does not validate password against username or other
required fields
---+-
 Reporter:  Josh Schneier  |Owner:  Josh Schneier
 Type:  Bug|   Status:  assigned
Component:  contrib.auth   |  Version:  2.1
 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):

 * stage:  Unreviewed => Accepted


-- 
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.96bb100d5775b5587a688a0b4b3f835a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29628: createsuperuser does not validate password against username or other required fields

[Django]

#29628: createsuperuser does not validate password against username or other
required fields
---+-
 Reporter:  Josh Schneier  |Owner:  Josh Schneier
 Type:  Bug|   Status:  assigned
Component:  contrib.auth   |  Version:  2.1
 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 Josh Schneier):

 Username isn’t included in fake user data and the validation runs inside
 of the for loop before all fields can be collected. I have failing test
 cases I just pushed up in a 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/067.6c0a7fdfa72f2242990003bffda2df46%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29625: Expose RelatedManager._remove_prefetched_objects as public method

[Django]

#29625: Expose RelatedManager._remove_prefetched_objects as public method
-+-
 Reporter:  Ming Qin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  _prefetched_objects_cache  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 Replying to [comment:5 Ming Qin]:
 > No, it doesn't work. Still hits the cache. Tested on `master`, `2.1rc1`,
 and `2.1`.
 > I'll be happy to fix `refresh_from_db`, instead of opening this new API.
 >
 > Does the following behavior sound good?
 > 1. If `refresh_from_db()` is called without argument, it **won't** clear
 prefetched cache.
 > 2. If it's called specifically with an related field, and that field is
 many-to-many or many-to-one field, the prefetched cache **will** be
 cleared.
 >

 1. No, it should clear all fields prefetched cache like it does right now
 with non-prefetched related manager cache.
 2. I haven't investigated but it looks like `ManyToManyField.is_cached`
 and `ManyToMany.delete_cached_value` might need to be redefined from
 `Field` in order to take `instance._prefetched_objects_cache` into
 consideration as well. It'd be interesting to test how prefetched  foreign
 keys and o2o behave here as well.

-- 
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/065.3d4cbd13aafaa39468e5daefa235f04b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29625: Expose RelatedManager._remove_prefetched_objects as public method

[Django]

#29625: Expose RelatedManager._remove_prefetched_objects as public method
-+-
 Reporter:  Ming Qin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  _prefetched_objects_cache  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ming Qin):

 Replying to [comment:4 Simon Charette]:
 > Could you confirm `refresh_from_db(fields=['authors'])` works on Django
 2.1? If not this might be an omission in #29076.

 No, it doesn't work. Still hits the cache. Tested on `master`, `2.1rc1`,
 and `2.1`.
 I'll be happy to fix `refresh_from_db`, instead of opening this new API.

 Does the following behavior sound good?
 1. If `refresh_from_db()` is called without argument, it **won't** clear
 prefetched cache.
 2. If it's called specifically with an related field, and that field is
 many-to-many or many-to-one field, the prefetched cache **will** be
 cleared.

-- 
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/065.d7ffc69b9bde3720bfa290f208b89c6e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29628: createsuperuser does not validate password against username or other required fields (was: Createsuperuser does not validate password against username or other required fields)

[Django]

#29628: createsuperuser does not validate password against username or other
required fields
---+-
 Reporter:  Josh Schneier  |Owner:  Josh Schneier
 Type:  Bug|   Status:  assigned
Component:  contrib.auth   |  Version:  2.1
 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 Tim Graham):

 It looks to me like it does (as of
 53d28f83390aed98fab4eed187eaf1edaa92c6d0). Is there a bug with the
 `fake_user_data` approach?

-- 
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.22d4aeeb1e8bbbda8201802508a9b0a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29627: QueryDict.urlencode() crashes on non-string values (was: QueryDict.urlencode() behaviour changed)

[Django]

#29627: QueryDict.urlencode() crashes on non-string values
-+
 Reporter:  Rafał P. |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  2.1
 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
-+
Changes (by Tim Graham):

 * component:  Uncategorized => HTTP handling
 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Bisected to 7d96f0c49ab750799860e42716d7105e11de44de. We might restore the
 old behavior.

-- 
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/065.0d5dd875396ee251aa1ee07ed8aed7e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29625: Expose RelatedManager._remove_prefetched_objects as public method

[Django]

#29625: Expose RelatedManager._remove_prefetched_objects as public method
-+-
 Reporter:  Ming Qin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  _prefetched_objects_cache  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 Could you confirm `refresh_from_db(fields=['authors'])` works on Django
 2.1? If not this might be an omission in #29076.

-- 
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/065.8942af08aa44d07dea7d260088e14afb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29625: Expose RelatedManager._remove_prefetched_objects as public method

[Django]

#29625: Expose RelatedManager._remove_prefetched_objects as public method
-+-
 Reporter:  Ming Qin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  _prefetched_objects_cache  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ming Qin):

 Yeah as Tim said, `refresh_from_db()` doesn't help in this case. I did an
 experiment just to confirm:
 {{{
 #!python
 >>> book1.refresh_from_db()
 >>> book1.refresh_from_db(fields=["authors"])
 >>> list(book1.authors.all())  # still hits the prefetched cache
 }}}

-- 
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/065.9e0303b9b64e372dca182cf92070a401%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29628: Createsuperuser does not validate password against username or other required fields

[Django]

#29628: Createsuperuser does not validate password against username or other
required fields
---+-
 Reporter:  Josh Schneier  |Owner:  Josh Schneier
 Type:  Bug|   Status:  assigned
Component:  contrib.auth   |  Version:  2.1
 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 Josh Schneier):

 * owner:  nobody => Josh Schneier
 * 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/067.126de687558f3dc09f6a4abe79b8fcb2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29628: Createsuperuser does not validate password against username or other required fields

[Django]

#29628: Createsuperuser does not validate password against username or other
required fields
-+
   Reporter:  Josh Schneier  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.auth   |Version:  2.1
   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  |
-+


-- 
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/052.e7a838c587248d0cd8567f50057ff80e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29627: QueryDict.urlencode() behaviour changed

[Django]

#29627: QueryDict.urlencode() behaviour changed
-+
   Reporter:  Rafał P.   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.1
   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  |
-+
 In version 2.0 it was possible to pass integer values to QueryDict and
 urlencode() it:
 {{{
 from django.http import QueryDict
 d = QueryDict('', mutable=True)
 d["a"] = 1
 d.urlencode()
 'a=1'
 }}}
 in 2.1 it raises `AttributeError: 'int' object has no attribute 'encode'`.
 I think this should be listed as backward - incompatible change in the
 [https://docs.djangoproject.com/en/2.1/releases/2.1/ 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/050.ade8e95e8af4babfee21e62561b2cbfe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27869: Add fastupdate and gin_pending_list_limit parameters to GinIndex

[Django]

#27869: Add fastupdate and gin_pending_list_limit parameters to GinIndex
-+-
 Reporter:  Mads Jensen  |Owner:  Tim
 |  Graham 
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   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:"743d28f5539b17d6e39bd37c6e3df5628b470cac" 743d28f]:
 {{{
 #!CommitTicketReference repository=""
 revision="743d28f5539b17d6e39bd37c6e3df5628b470cac"
 Refs #27869 -- Added PostgreSQL version check for GinIndex support.
 }}}

-- 
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.4bc9eca6b9089cb029e578b209f45bdc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28990: Add autosummarize parameter to BrinIndex

[Django]

#28990: Add autosummarize parameter to BrinIndex
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  brin,| Triage Stage:  Ready for
  autosummarize, index, postgres,|  checkin
  db-indexes |
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:"ff9543b351e79de78e7867f255ad15e51555ba4a" ff9543b]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff9543b351e79de78e7867f255ad15e51555ba4a"
 Refs #25809, #28990 -- Added PostgreSQL version check for BrinIndex
 support.
 }}}

-- 
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/065.e2f31608775ea8cfa9b97d42b7e99985%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25809: PostgreSQL 9.5 BRIN Index support in contrib.postgres

[Django]

#25809: PostgreSQL 9.5 BRIN Index support in contrib.postgres
-+-
 Reporter:  Asif Saifuddin Auvi  |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgres, index, | Triage Stage:  Ready for
  BRIN, db-indexes   |  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:"ff9543b351e79de78e7867f255ad15e51555ba4a" ff9543b]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff9543b351e79de78e7867f255ad15e51555ba4a"
 Refs #25809, #28990 -- Added PostgreSQL version check for BrinIndex
 support.
 }}}

-- 
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.a24b220f4b1b5cfd37953703f15412e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29614: Add fillfactor parameter for B-Tree indexes

[Django]

#29614: Add fillfactor parameter for B-Tree indexes
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  btree, index,| Triage Stage:  Ready for
  postgres, db-indexes, fillfactor   |  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:"6b4d1ec8ff97cff4f1683912b0147d22410b05b8" 6b4d1ec]:
 {{{
 #!CommitTicketReference repository=""
 revision="6b4d1ec8ff97cff4f1683912b0147d22410b05b8"
 Fixed #29614 -- Added BTreeIndex to django.contrib.postres.
 }}}

-- 
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/065.bd80b745354a733cacf83f5d26cea54f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28990: Add autosummarize parameter to BrinIndex

[Django]

#28990: Add autosummarize parameter to BrinIndex
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  brin,| Triage Stage:  Ready for
  autosummarize, index, postgres,|  checkin
  db-indexes |
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:"d6381d3559b469ce25f4906151b9329c1f946f14" d6381d35]:
 {{{
 #!CommitTicketReference repository=""
 revision="d6381d3559b469ce25f4906151b9329c1f946f14"
 Fixed #28990 -- Added autosummarize parameter to BrinIndex.
 }}}

-- 
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/065.e29d66efce985eaf87e19b77c5ac9353%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29623: DurationField ValidationError message should use proper gettext variables

[Django]

#29623: DurationField ValidationError message should use proper gettext 
variables
-+-
 Reporter:  Jannis Leidel|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  2.1
 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:  1|UI/UX:  0
-+-

Comment (by Markus Holtermann):

 I don't think the `.format()` option works with gettext though, does it?

-- 
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.34b87ef9d8cda5e1a8e834ddd16b6277%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28887: Add support for SP-Gist indexes

[Django]

#28887: Add support for SP-Gist indexes
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  spgist, index,   | Triage Stage:  Ready for
  postgres, db-indexes   |  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:"4c36e9e492b5c127d839ebf280fdf5556af8e824" 4c36e9e4]:
 {{{
 #!CommitTicketReference repository=""
 revision="4c36e9e492b5c127d839ebf280fdf5556af8e824"
 Fixed #28887 -- Added SpGistIndex to django.contrib.postgres.
 }}}

-- 
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/065.5637031344e64ff8cf86cdc4faee83a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29499: Race condition in QuerySet.update_or_create()

[Django]

#29499: Race condition in QuerySet.update_or_create()
-+-
 Reporter:  Michael Sanders  |Owner:  Michael
 |  Sanders
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  race-condition   | 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 Simon Charette):

 I think it should be pretty safe to backport for the rare cases when this
 happens. It's really an edge case but as Michael demonstrated in his test
 it can effectively lead to data-losses.

-- 
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.c06e21416cd4b7a6351161e0609d8d36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26974: Add support for Hash indexes

[Django]

#26974: Add support for Hash indexes
-+-
 Reporter:  Akshesh Doshi|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  hash, index, | Triage Stage:  Ready for
  postgres, db-indexes   |  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:"d526b07784d8caa208055c1f2bd1cedc88fb52dc" d526b077]:
 {{{
 #!CommitTicketReference repository=""
 revision="d526b07784d8caa208055c1f2bd1cedc88fb52dc"
 Fixed #26974 -- Added HashIndex to django.contrib.postgres.

 Thanks Akshesh Doshi for the initial implementation.
 }}}

-- 
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/062.016075c0a982cadea33487c7d536a059%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29622: Indexes on JSONB paths fail system checks in 2.1

[Django]

#29622: Indexes on JSONB paths fail system checks in 2.1
--+
 Reporter:  James Howe|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  2.1
 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):

 * severity:  Release blocker => Normal


Comment:

 This is not a release blocker in this case.

 @Josh I don't think we should ship a special index for this case. #26167
 will add support for functional indices where the above will be
 expressible using `KeyTransform`s.

 Not sure if this ticket should be closed as duplicate of #26167 or a new
 ticket should be opened (or this one renamed) to add support for string
 transforms to `Index` to reduce the boiler plate required to define a
 functional index.

 e.g.

 - `Index('join_date__year')` instead of `Index(ExtractYear('join_date'))`
 - `Index('json_field__property')` instead of
 `Index(KeyTransform('property', 'json_field'))`.

-- 
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.adf0b90f61d23f914e1f528c6c162874%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29625: Expose RelatedManager._remove_prefetched_objects as public method

[Django]

#29625: Expose RelatedManager._remove_prefetched_objects as public method
-+-
 Reporter:  Ming Qin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  _prefetched_objects_cache  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 I don't really like an additional method either but `refresh_from_db()`
 only reloads model fields -- it doesn't clear related manager caches, so I
 guess this might be okay. Prefetch related cache clearing was added in
 #26706.

-- 
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/065.abdb31ba6f7521f8f5ac3a50034b93ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29600: Remove usage of django.utils.datetime_safe where possible

[Django]

#29600: Remove usage of django.utils.datetime_safe where possible
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 GitHub ):

 In [changeset:"2092206bee3281e6809a8fddb5230d80902a02b4" 2092206b]:
 {{{
 #!CommitTicketReference repository=""
 revision="2092206bee3281e6809a8fddb5230d80902a02b4"
 Refs #29600 -- Updated django.utils.datetime_safe now that Python 2 is
 unsupported.
 }}}

-- 
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.8caa89882bb1236fd125ad9def129849%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29499: Race condition in QuerySet.update_or_create()

[Django]

#29499: Race condition in QuerySet.update_or_create()
-+-
 Reporter:  Michael Sanders  |Owner:  Michael
 |  Sanders
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  race-condition   | 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):

 Do you think we should backport to 1.11 based on your comment about data
 loss?

-- 
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.f2309947ffc4e86ba30b4a3c6f39d902%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29613: Allow --keepdb to work on PostgreSQL if the database exists but the user can't create databases

[Django]

#29613: Allow --keepdb to work on PostgreSQL if the database exists but the user
can't create databases
+
 Reporter:  Paul McDermott  |Owner:  felixxm
 Type:  Bug |   Status:  assigned
Component:  Testing framework   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  postgres, --keepdb  | 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):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10260 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/069.bb24ed49273df345b8ea8c8c822b48a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29620: Document possible performance benefits from transactions

[Django]

#29620: Document possible performance benefits from transactions
---+--
 Reporter:  WGH|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.0
 Severity:  Normal |   Resolution:  needsinfo
 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 Carlton Gibson):

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


Comment:

 I'm not sure whether to accept this or not: if the doc-change was good
 then, sure, yes, great. Otherwise it may just confuse the matter.
 I don't think the advice it wrong for the bulk of common cases.

 Are you up for making the patch yourself? If so perhaps you could draft
 something up and open a PR so we can assess whether it makes sense?

 I'll close this as `needsinfo` pending that. Please re-open as/when you
 can expand.
 Thanks!

-- 
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/062.d4b64e8161a57b809748654422b06af6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29625: Expose RelatedManager._remove_prefetched_objects as public method

[Django]

#29625: Expose RelatedManager._remove_prefetched_objects as public method
-+-
 Reporter:  Ming Qin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:
  _prefetched_objects_cache  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Not sure about the value of adding this. We already have
 
[https://docs.djangoproject.com/en/2.0/ref/models/instances#django.db.models.Model.refresh_from_db
 `refresh_from_db()`] available.

 A public `remove_prefetched_objects()` would be more fine-grained, yes,
 but I'm not sure it would be worth the extra API surface area,
 documentation and potential for user-confusion.
 (''"Just use `refresh_from_db()`"'' is nice and clear.)

-- 
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/065.6b22fdb1e70a45c7e8907cb159dc8748%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29626: cache.backends.db does not implement delete_many()

[Django]

#29626: cache.backends.db does not implement delete_many()
--+
 Reporter:  oliver|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  master
 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
--+
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 This seems reasonable given #29584.
 (Possibly merge?)

-- 
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.95af150d0e09c72f6a9da01abcb229fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29623: DurationField ValidationError message should use proper gettext variables

[Django]

#29623: DurationField ValidationError message should use proper gettext 
variables
-+-
 Reporter:  Jannis Leidel|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  2.1
 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:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch seems fine.

 (Slight niggle: Isn't %-style string formatting discouraged now? Does this
 kind of consideration block moving away from it, assuming that's
 desirable?)

-- 
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.6ecbe792f4d63489dbb249a7cac96681%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29622: Indexes on JSONB paths fail system checks in 2.1

[Django]

#29622: Indexes on JSONB paths fail system checks in 2.1
--+
 Reporter:  James Howe|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  2.1
 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 James Howe):

 > How did this ever work

 Ah, I also have a custom SQL migration so I could make it partial.

 Adding {{{'models.E012'}}} to {{{SILENCED_SYSTEM_CHECKS}}} should give
 exactly the same behaviour as in 2.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 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.e7feb8e62cd7d8064577f4e71924e9bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28887: Add support for SP-Gist indexes

[Django]

#28887: Add support for SP-Gist indexes
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  spgist, index,   | Triage Stage:  Ready for
  postgres, db-indexes   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


-- 
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/065.691fdbee9fc9caf60db4f613cc6236c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26974: Add support for Hash indexes

[Django]

#26974: Add support for Hash indexes
-+-
 Reporter:  Akshesh Doshi|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  hash, index, | Triage Stage:  Ready for
  postgres, db-indexes   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


-- 
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/062.8fd366574039dbc2978fa44a9cbb1528%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28990: Add autosummarize parameter to BrinIndex

[Django]

#28990: Add autosummarize parameter to BrinIndex
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  brin,| Triage Stage:  Ready for
  autosummarize, index, postgres,|  checkin
  db-indexes |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


-- 
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/065.d05180b6d2fb8c04198da38d3383d90d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29614: Add fillfactor parameter for B-Tree indexes

[Django]

#29614: Add fillfactor parameter for B-Tree indexes
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  btree, index,| Triage Stage:  Ready for
  postgres, db-indexes, fillfactor   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


-- 
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/065.2f4d0675dd2d31e5e10460632dbe1484%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.