Re: [Django] #29641: Add support for unique constraints to Meta.constraints

[Django]

#29641: Add support for unique constraints to Meta.constraints
-+-
 Reporter:  Simon Charette   |Owner:  (none)
 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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * status:  assigned => new
 * owner:  Simon Charette => (none)
 * has_patch:  0 => 1


Comment:

 Ian started adjusting my initial PR in
 https://github.com/django/django/pull/10337.

 I'd be great to get the commits referencing #29641 in before the 2.2
 release as they are mostly adjustments that will be hard to perform if we
 commit to the currently documented interface.

 I'd review it but since I've written a large chunk of this code it's a bit
 hard for me to do it.

 I'm deassigning the ticket given Ian's work so far, feel free to claim the
 ticket Ian.

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

Re: [Django] #29712: Add warning in makemessages command if the localecode with `l` flag is not correct

[Django]

#29712: Add warning in makemessages command if the localecode with `l` flag is 
not
correct
-+-
 Reporter:  Sanyam Khurana   |Owner:  Matt
 Type:   |  Segal
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Matt Segal):

 PR Ready

 [https://github.com/django/django/pull/10345]

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

Re: [Django] #28223: Form not always picklable due to template renderer

[Django]

#28223: Form not always picklable due to template renderer
--+-
 Reporter:  Claude Paroz  |Owner:  Gaurav Sehgal
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by za):

 Is this bug related with this
 https://docs.djangoproject.com/en/2.1/releases/1.11/#django-template-
 backends-django-template-render-prohibits-non-dict-context ?

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

Re: [Django] #29717: Provide a way for tests to run on an existing empty DB

[Django]

#29717: Provide a way for tests to run on an existing empty DB
-+-
 Reporter:  Curtis Maloney   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Curtis Maloney):

 To clarify...

 Basically, I want to separate create/drop of the DB with create/drop of
 the objects within the DB, where currently we conflate the concepts.

 Currently we have "must create db" vs. "may reuse db"

 So we allow "must create db" which implies "must start clean"
 We can do "may reuse db", but that currently forces "may reuse objects".

 I'm trying to enable "may reuse db" with "must start clean".

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

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

[Django] #29721: Migrations are not applied atomically

[Django]

#29721: Migrations are not applied atomically
-+
   Reporter:  Gavin Wahl |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Migrations |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  |
-+
 Migrations run the migration and record that the migration was applied in
 a different transaction. This results in a broken/inconsistent database
 when an error or crash happens between those two steps. This is not purely
 theoretical, it has happened to me.

 The executor needs to call migration.apply and record_applied in the same
 transaction, and then the django_migrations table can't get out of sync
 with the migrations that have actually been applied. I think this could be
 done by moving the call to record_applied inside the schema_editor context
 manager block.

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

[Django] #29720: Validating migrations using manage.py

[Django]

#29720: Validating migrations using manage.py
-+-
   Reporter:  tombasche  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  2.1
  Migrations |   Keywords:  migrations,
   Severity:  Normal |  manage.py, validation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 At work we have several Django services each with several apps. Usually
 after a few devs merge pull requests into the main branch in Git we get
 migrations with the same number. From time to time there's also some
 reordering with dependencies in migrations leap-frogging the previous one.

 This obviously gets picked up at run time, but it would be cool to be able
 to determine this at build time. Obviously we should all take more care,
 but I would consider this more of a "linting" stage than anything else.

 In the interim I wrote (or rather, hacked together) a cli tool that
 validates this, but ultimately this would be better suited as a manage.py
 command. Something like {{{manage.py validate-migrations }}}. All it has
 to do is check the migration numbers are incremental and that their
 dependencies refer to the previous migration in the list.

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

Re: [Django] #29719: Allow inspectdb to introspect foreign data wrapper tables

[Django]

#29719: Allow inspectdb to introspect foreign data wrapper tables
-+-
 Reporter:  Luke |Owner:  Luke
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  postgres,fdw,foreign data wrapper  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Luke:

Old description:

> When running the "inspectdb" command against a postgres database with
> foreign data wrapper (fdw) tables, these foreign tables aren't listed.
>
> The bug arises here
> line#41 of db/backends/postgresql/introspection.py
>

>
> {{{
> SELECT c.relname, c.relkind
> FROM pg_catalog.pg_class c
> LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
> WHERE c.relkind IN ('r', 'v')
> AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
> AND pg_catalog.pg_table_is_visible(c.oid)""")
> }}}
>
> pg_class.relkind stores foreign tables as "F" , so the condition
> "c.relkind in ('r','v')" is never met .
>
> The query must be rewritten as
>

> {{{
> SELECT c.relname, c.relkind
> FROM pg_catalog.pg_class c
> LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
> WHERE c.relkind IN ('r', 'v', 't')
> AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
> AND pg_catalog.pg_table_is_visible(c.oid)""")
> }}}
>
> and on line#50
>

> {{{
> return [TableInfo(row[0], {'r': 't', 'v': 'v', 'f': 't'}.get(row[1]))
> for row in cursor.fetchall()
> if row[0] not in self.ignored_tables]
> }}}
> in order to map the 'f' to a table
>
> I patched the file and made this pull-request
>
> https://github.com/django/django/pull/10351

New description:

 When running the "inspectdb" command against a postgres database with
 foreign data wrapper (fdw) tables, these foreign tables aren't listed.

 The bug arises here
 line#41 of db/backends/postgresql/introspection.py



 {{{
 SELECT c.relname, c.relkind
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid)""")
 }}}

 pg_class.relkind stores foreign tables as "F" , so the condition
 "c.relkind in ('r','v')" is never met .

 The query must be rewritten as


 {{{
 SELECT c.relname, c.relkind
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v', 't')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid)""")
 }}}

 and on line#50


 {{{
 return [TableInfo(row[0], {'r': 't', 'v': 'v', 'f': 't'}.get(row[1]))
 for row in cursor.fetchall()
 if row[0] not in self.ignored_tables]
 }}}
 in order to map the 'f' to a table

 I patched the file and made this pull-request

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

Re: [Django] #29719: Allow inspectdb to introspect foreign data wrapper tables (was: command inspectdb run against postgres' foreign data wrapper (fdw) fails to list the foreign tables)

[Django]

#29719: Allow inspectdb to introspect foreign data wrapper tables
-+-
 Reporter:  Luke |Owner:  Luke
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  postgres,fdw,foreign data wrapper  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted
 * type:  Bug => New feature
 * easy:  1 => 0
 * needs_tests:  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 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/071.9b4df0e8ba8ae4a8e38aeac4999376fe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29719: command inspectdb run against postgres' foreign data wrapper (fdw) fails to list the foreign tables

[Django]

#29719: command inspectdb run against postgres' foreign data wrapper (fdw) 
fails to
list the foreign tables
-+-
 Reporter:  Luke |Owner:  Luke
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  postgres,fdw,foreign data wrapper  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Luke:

Old description:

> When running the "inspectdb" command against a postgres database with
> foreign data wrapper (fdw) tables, these foreign tables aren't listed.
>
> The bug arises here
> line#41 of db/backends/postgresql/introspection.py
>

>
> {{{
> SELECT c.relname, c.relkind
> FROM pg_catalog.pg_class c
> LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
> WHERE c.relkind IN ('r', 'v')
> AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
> AND pg_catalog.pg_table_is_visible(c.oid)""")
> }}}
>
> pg_class.relkind stores foreign tables as "F" , so the condition
> "c.relkind in ('r','v')" is never met .
>
> The query must be rewritten as
>

> {{{
> SELECT c.relname, c.relkind
> FROM pg_catalog.pg_class c
> LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
> WHERE c.relkind IN ('r', 'v', 't')
> AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
> AND pg_catalog.pg_table_is_visible(c.oid)""")
> }}}
>
> and on line#50
>

> {{{
> return [TableInfo(row[0], {'r': 't', 'v': 'v', 'f': 't'}.get(row[1]))
> for row in cursor.fetchall()
> if row[0] not in self.ignored_tables]
> }}}
> in order to map the 'f' to a table

New description:

 When running the "inspectdb" command against a postgres database with
 foreign data wrapper (fdw) tables, these foreign tables aren't listed.

 The bug arises here
 line#41 of db/backends/postgresql/introspection.py



 {{{
 SELECT c.relname, c.relkind
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid)""")
 }}}

 pg_class.relkind stores foreign tables as "F" , so the condition
 "c.relkind in ('r','v')" is never met .

 The query must be rewritten as


 {{{
 SELECT c.relname, c.relkind
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v', 't')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid)""")
 }}}

 and on line#50


 {{{
 return [TableInfo(row[0], {'r': 't', 'v': 'v', 'f': 't'}.get(row[1]))
 for row in cursor.fetchall()
 if row[0] not in self.ignored_tables]
 }}}
 in order to map the 'f' to a table

 I patched the file and made this pull-request

 https://github.com/django/django/pull/10351

--

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

[Django] #29719: command inspectdb run against postgres' foreign data wrapper (fdw) fails to list the foreign tables

[Django]

#29719: command inspectdb run against postgres' foreign data wrapper (fdw) 
fails to
list the foreign tables
-+-
   Reporter:  Luke   |  Owner:  Luke
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  2.1
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  postgres,fdw,foreign data wrapper
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 When running the "inspectdb" command against a postgres database with
 foreign data wrapper (fdw) tables, these foreign tables aren't listed.

 The bug arises here
 line#41 of db/backends/postgresql/introspection.py



 {{{
 SELECT c.relname, c.relkind
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid)""")
 }}}

 pg_class.relkind stores foreign tables as "F" , so the condition
 "c.relkind in ('r','v')" is never met .

 The query must be rewritten as


 {{{
 SELECT c.relname, c.relkind
 FROM pg_catalog.pg_class c
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relkind IN ('r', 'v', 't')
 AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 AND pg_catalog.pg_table_is_visible(c.oid)""")
 }}}

 and on line#50


 {{{
 return [TableInfo(row[0], {'r': 't', 'v': 'v', 'f': 't'}.get(row[1]))
 for row in cursor.fetchall()
 if row[0] not in self.ignored_tables]
 }}}
 in order to map the 'f' to a table

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

Re: [Django] #29718: Document admin template collision backwards incompatibility in Django 2.1

[Django]

#29718: Document admin template collision backwards incompatibility in Django 
2.1
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.1
 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 Tim Graham ):

 In [changeset:"c4559d0b39087e82a546c16e7412a7c097787bf0" c4559d0b]:
 {{{
 #!CommitTicketReference repository=""
 revision="c4559d0b39087e82a546c16e7412a7c097787bf0"
 [2.1.x] Fixed #29718 -- Doc'd admin template collision backwards
 incompatibility in Django 2.1.

 Backport of 166dec84069c15ecb2bc3a5590f872febdc4709c 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/067.d499e16f3a7d0ff69fe048ccb28a8150%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29718: Document admin template collision backwards incompatibility in Django 2.1

[Django]

#29718: Document admin template collision backwards incompatibility in Django 
2.1
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by GitHub ):

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


Comment:

 In [changeset:"166dec84069c15ecb2bc3a5590f872febdc4709c" 166dec84]:
 {{{
 #!CommitTicketReference repository=""
 revision="166dec84069c15ecb2bc3a5590f872febdc4709c"
 Fixed #29718 -- Doc'd admin template collision backwards incompatibility
 in Django 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/067.da20b143e42aca108a1f5e2f98118eee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29534: Use rlwrap if available for oracle backend dbshell

[Django]

#29534: Use rlwrap if available for oracle backend dbshell
-+-
 Reporter:  Dan Davis|Owner:  Dan Davis
 Type:   |   Status:  assigned
  Cleanup/optimization   |
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:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: felixxm (added)
 * needs_better_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 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.fff2ee22a784eb0698723b5367c61bc8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29711: One can use as actions functions generated only by the first call to another function

[Django]

#29711: One can use as actions functions generated only by the first call to
another function
-+-
 Reporter:  Przemysław   |Owner:  nobody
  Buczkowski |
 Type:  Uncategorized|   Status:  closed
Component:  contrib.admin|  Version:  2.1
 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
-+-

Comment (by Przemysław Buczkowski):

 Yes, you're right, the opposite happens - I got a bit confused :)

 Do you think that a warning should be added to Django docs? I can provide
 a patch to the docs since I don't think that this behaviour is obvious,
 even if it's intended - but maybe that's just 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 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.be205eedd28c1380d794f098539a794d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29717: Provide a way for tests to run on an existing empty DB

[Django]

#29717: Provide a way for tests to run on an existing empty DB
-+-
 Reporter:  Curtis Maloney   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 As I said on [https://groups.google.com/d/topic/django-developers/AF-
 5K4atdF4/discussion django-developers], I don't see why we couldn't
 recommend `--keepdb` for this use case?

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

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

Re: [Django] #29718: Document admin template collision backwards incompatibility in Django 2.1

[Django]

#29718: Document admin template collision backwards incompatibility in Django 
2.1
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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
--+

Comment (by Tim Graham):

 #28935 could be the issue about the incorrect debug page location.

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

Re: [Django] #29718: Document admin template collision backwards incompatibility in Django 2.1 (was: Small backwards-incompatibility in Django 2.1)

[Django]

#29718: Document admin template collision backwards incompatibility in Django 
2.1
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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 Tim Graham):

 * has_patch:  0 => 1
 * component:  contrib.admin => Documentation
 * stage:  Unreviewed => Accepted


Comment:

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

Re: [Django] #29718: Small backwards-incompatibility in Django 2.1

[Django]

#29718: Small backwards-incompatibility in Django 2.1
-+-
 Reporter:  Aymeric Augustin |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  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 Aymeric Augustin):

 * Attachment "Capture d’écran 2018-08-28 à 14.04.32.png" 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 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.dde5762c29792c4bf6a175c26f1816c9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

[Django]

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   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
-+-

Comment (by Tim Graham ):

 In [changeset:"ee184e13cba1dbb3ec6fc5ec32ec035ceebcb991" ee184e1]:
 {{{
 #!CommitTicketReference repository=""
 revision="ee184e13cba1dbb3ec6fc5ec32ec035ceebcb991"
 Refs #27795 -- Removed force_bytes() usage in django/utils/cache.py.
 }}}

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

[Django] #29718: Small backwards-incompatibility in Django 2.1

[Django]

#29718: Small backwards-incompatibility in Django 2.1
+
   Reporter:  Aymeric Augustin  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |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 |
+
 I have a `cupido.Device` Model and a corresponding ModelAdmin with a
 custom view that renders a template called
 `admin/cupido/device/search_form.html`.

 After upgrading to Django 2.1, the changelist view crashes with a very
 confusing error:

 {{{
 NoReverseMatch at /admin/cupido/device/
 Reverse for 'app_list' with keyword arguments '{'app_label': ''}' not
 found. 1 pattern(s) tried: ['admin\\/(?Pauth|cupido)/$']
 }}}

 This is because Django now supports overriding
 `admin///search_form.html` and picks up my
 template, which breaks because it was written for a completely different
 purpose. This pitfall — the risk of collision with preexisting templates —
 could be mentioned in the 2.1 release notes.

 Furthermore, the debug view doesn't identify the correct line. It says
 there's an error at line 11 (see attachment) but I couldn't identify any
 template in which a line 11 contains a `{% url ... %}` tag that could
 result in this error. I have no idea what's happening there; I couldn't
 put together a good bug report for that problem.

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

Re: [Django] #29712: Add warning in makemessages command if the localecode with `l` flag is not correct

[Django]

#29712: Add warning in makemessages command if the localecode with `l` flag is 
not
correct
-+-
 Reporter:  Sanyam Khurana   |Owner:  MattSegal
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * has_patch:  0 => 1
 * version:  2.1 => master
 * type:  Bug => Cleanup/optimization
 * needs_tests:  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 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/072.6fd916b89f3cda2f4f843536cad2b9e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29654: Truncate should use horizontal ellipsis character instead of three dots

[Django]

#29654: Truncate should use horizontal ellipsis character instead of three dots
-+-
 Reporter:  Sudhanshu Mishra |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  string, truncator| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"5311a36da53f33645aa1938f6790228b57ea2d9a" 5311a36]:
 {{{
 #!CommitTicketReference repository=""
 revision="5311a36da53f33645aa1938f6790228b57ea2d9a"
 Refs #29654 -- Replaced three dots with ellipsis in DB creation output
 strings.
 }}}

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

Re: [Django] #29713: Add a django check to ensure the LANGUAGE_CODE setting uses the standard language ID format

[Django]

#29713: Add a django check to ensure the LANGUAGE_CODE setting uses the standard
language ID format
--+
 Reporter:  Ian Foote |Owner:  David
 Type:  New feature   |   Status:  assigned
Component:  Internationalization  |  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 Claude Paroz):

 * needs_better_patch:  1 => 0
 * 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.f5550b33abeac03ec168fc5d6a57df55%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27795: Audit force_text invocations

[Django]

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   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
-+-

Comment (by Tim Graham ):

 In [changeset:"90f3ef332b0274d066c9bc2d7f41242f755f7187" 90f3ef3]:
 {{{
 #!CommitTicketReference repository=""
 revision="90f3ef332b0274d066c9bc2d7f41242f755f7187"
 Refs #27795 -- Removed force_bytes()/smart_text() from model fields.
 }}}

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

Re: [Django] #29716: Add a warning in LocaleMiddleware is after CommonMiddleware or before SessionMiddelware

[Django]

#29716: Add a warning in LocaleMiddleware is after CommonMiddleware or before
SessionMiddelware
-+-
 Reporter:  Sanyam Khurana   |Owner:  Sanyam
 |  Khurana
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  wontfix
 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 Claude Paroz):

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


Comment:

 See ticket #15902, the language is now (from Django 2.1) also stored in a
 cookie, that's why I think the issue you mention should not happen again
 in the future.

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

[Django] #29717: Provide a way for tests to run on an existing empty DB

[Django]

#29717: Provide a way for tests to run on an existing empty DB
-+-
   Reporter:  Curtis |  Owner:  nobody
  Maloney|
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  2.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Periodically users ask in IRC for help running tests when the user they
 connect as can not create a DB.

 The reasons for this situation tend to be their DBA won't allow it, or
 their corporate policy doesn't permit it.

 Regardless, Django fails because when not using keepdb, it attempts to
 create the db _always_, and only catches "duplicate DB name" errors to
 indicate it already exists.

 However, Postgres checks for CREATE DB permissions _before_ checking if
 the DB exists, so Django sees it as a generic "DB creation problem" and
 bails.

 If we, instead, used the existing function [used by the keepdb logic] to
 test if the DB exists, we could smooth the path for users in the above
 situation.

 I've started a patch which is currently _very_ wrong, and is awaiting
 feedback as requested on the django-dev mailing list.

 https://github.com/django/django/pull/10349

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