date:20170314

Re: [Django] #27940: Migrations fail when when a model's parent class is changed to abstract -- Wrong SQL being generated

2017-03-14 Thread Django

#27940: Migrations fail when when a model's parent class is changed to abstract 
--
Wrong SQL being generated
-+-
 Reporter:  sawan|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  SQLite migrations| Triage Stage:
  abstract inheritance   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by sawan:

Old description:

> Consider the following class hierarchy:
>
> {{{
> #!python
> class TestCase(models.Model):
> name = models.CharField(max_length=10)
>
> class TerminalTest(TestCase):
> pass
>
> class BrowserTest(TestCase):
> pass
>
> $ ./manage.py makemigrations testbed
> Migrations for 'testbed':
>   testbed\migrations\0001_initial.py:
> - Create model TestCase
> - Create model BrowserTest
> - Create model TerminalTest
>
> $ ./manage.py migrate testbed
> Operations to perform:
>   Apply all migrations: testbed
> Running migrations:
> Applying testbed.0001_initial... OK
> }}}
>
> Now we want to make the parent an abstract class:
>
> {{{
> #!python
> class TestCase(models.Model):
> name = models.CharField(max_length=10)
>
> class Meta:
> abstract = True
>
> class TerminalTest(TestCase):
> pass
>
> class BrowserTest(TestCase):
> pass
>
> $ ./manage.py migrate testbed
> Operations to perform:
>   Apply all migrations: testbed
> Running migrations:
>   Applying testbed.0002_auto_20170315_1600...Traceback (most recent call
> last):
>   File "C:\my-venv\lib\site-packages\django\db\backends\utils.py", line
> 64, in execute
> return self.cursor.execute(sql, params)
>   File "C:\my-venv\lib\site-packages\django\db\backends\sqlite3\base.py",
> line 337, in execute
> return Database.Cursor.execute(self, query, params)
> sqlite3.OperationalError: near ")": syntax error
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "C:\my-venv\lib\site-packages\django\core\management\__init__.py",
> line 367, in execute_from_command_line
> utility.execute()
>   File "C:\my-venv\lib\site-packages\django\core\management\__init__.py",
> line 359, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "C:\my-venv\lib\site-packages\django\core\management\base.py",
> line 294, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "C:\my-venv\lib\site-packages\django\core\management\base.py",
> line 345, in execute
> output = self.handle(*args, **options)
>   File "C:\my-venv\lib\site-
> packages\django\core\management\commands\migrate.py", line 204, in handle
> fake_initial=fake_initial,
>   File "C:\my-venv\lib\site-packages\django\db\migrations\executor.py",
> line 115, in migrate
> state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
> fake_initial=fake_initial)
>   File "C:\my-venv\lib\site-packages\django\db\migrations\executor.py",
> line 145, in _migrate_all_forwards
> state = self.apply_migration(state, migration, fake=fake,
> fake_initial=fake_initial)
>   File "C:\my-venv\lib\site-packages\django\db\migrations\executor.py",
> line 244, in apply_migration
> state = migration.apply(state, schema_editor)
>   File "C:\my-venv\lib\site-packages\django\db\migrations\migration.py",
> line 129, in apply
> operation.database_forwards(self.app_label, schema_editor, old_state,
> project_state)
>   File "C:\my-venv\lib\site-
> packages\django\db\migrations\operations\fields.py", line 147, in
> database_forwards
> schema_editor.remove_field(from_model,
> from_model._meta.get_field(self.name))
>   File "C:\my-venv\lib\site-
> packages\django\db\backends\sqlite3\schema.py", line 249, in remove_field
> self._remake_table(model, delete_fields=[field])
>   File "C:\my-venv\lib\site-
> packages\django\db\backends\sqlite3\schema.py", line 199, in
> _remake_table
> self.quote_name(model._meta.db_table),
>   File "C:\my-venv\lib\site-packages\django\db\backends\base\schema.py",
> line 112, in execute
> cursor.execute(sql, params)
>   File "C:\my-venv\lib\site-packages\django\db\backends\utils.py", line
> 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "C:\my-venv\lib\site-packages\django\db\backends\utils.py", line
> 64, in execute
> return self.cursor.execute(sql, params)
>   File "C:\my-venv\lib\site-packages\django\db\util

Re: [Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

2017-03-14 Thread Django

Comment (by David Sanders):

Replying to [comment:19 Tim Graham]:

> About "the manifest lists the final filename and any intermediates could
be dropped." -- is a ticket needed for this enhancement?

I think any ticket should be drop `CachedStaticFilesStorage` entirely.
Dropping intermediates for `ManifestStaticFilesStorage` only would likely
cause more confusion as one would not be able to switch between the two
storage types without side effects.

> I'm wondering if there should be some release notes and documentation
about this considering that it sort of looks like a bug to the untrained
eye. Should there really be multiple versions of some admin CSS files that
differ only in their hash (base.css, fonts.css, widgets.css)? Only
forms.css has different hashed files with difference contents. If a
project is uploading static files to some remote storage, the increased
disk usage and upload time due to the increased number of files could be a
nuisance.

Nothing wrong with more documentation, but if `CachedStaticFilesStorage`
is dropped it wouldn't be necessary since the intermediates could be
dropped (and originals too as an optional benefit).

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

Re: [Django] #27940: Migrations fail when when a model's parent class is changed to abstract -- Wrong SQL being generated (was: Migrations fail when when Models parent class is changed to abstract --

2017-03-14 Thread Django

#27940: Migrations fail when when a model's parent class is changed to abstract 
--
Wrong SQL being generated
-+-
 Reporter:  Sawan Vithlani   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  SQLite migrations| Triage Stage:
  abstract inheritance   |  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/063.cc7dd3eff4b547e08230a9c77120d2bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27940: Migrations fail when when Models parent class is changed to abstract -- Wrong SQL being generated

2017-03-14 Thread Django

#27940: Migrations fail when when Models parent class is changed to abstract --
Wrong SQL being generated
-+-
   Reporter:  Sawan  |  Owner:  nobody
  Vithlani   |
   Type:  Bug| Status:  new
  Component: |Version:  1.10
  Migrations |   Keywords:  SQLite migrations
   Severity:  Normal |  abstract inheritance
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Consider the following class hierarchy:

 {{{
 #!python
 class TestCase(models.Model):
 name = models.CharField(max_length=10)

 class TerminalTest(TestCase):
 pass

 class BrowserTest(TestCase):
 pass

 $ ./manage.py makemigrations testbed
 Migrations for 'testbed':
   testbed\migrations\0001_initial.py:
 - Create model TestCase
 - Create model BrowserTest
 - Create model TerminalTest

 $ ./manage.py migrate testbed
 Operations to perform:
   Apply all migrations: testbed
 Running migrations:
 Applying testbed.0001_initial... OK
 }}}

 Now we want to make the parent an abstract class:

 {{{
 #!python
 class TestCase(models.Model):
 name = models.CharField(max_length=10)

 class Meta:
 abstract = True

 class TerminalTest(TestCase):
 pass

 class BrowserTest(TestCase):
 pass

 $ ./manage.py migrate testbed
 Operations to perform:
   Apply all migrations: testbed
 Running migrations:
   Applying testbed.0002_auto_20170315_1600...Traceback (most recent call
 last):
   File "C:\my-venv\lib\site-packages\django\db\backends\utils.py", line
 64, in execute
 return self.cursor.execute(sql, params)
   File "C:\my-venv\lib\site-packages\django\db\backends\sqlite3\base.py",
 line 337, in execute
 return Database.Cursor.execute(self, query, params)
 sqlite3.OperationalError: near ")": syntax error

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "C:\my-venv\lib\site-packages\django\core\management\__init__.py",
 line 367, in execute_from_command_line
 utility.execute()
   File "C:\my-venv\lib\site-packages\django\core\management\__init__.py",
 line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\my-venv\lib\site-packages\django\core\management\base.py", line
 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "C:\my-venv\lib\site-packages\django\core\management\base.py", line
 345, in execute
 output = self.handle(*args, **options)
   File "C:\my-venv\lib\site-
 packages\django\core\management\commands\migrate.py", line 204, in handle
 fake_initial=fake_initial,
   File "C:\my-venv\lib\site-packages\django\db\migrations\executor.py",
 line 115, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "C:\my-venv\lib\site-packages\django\db\migrations\executor.py",
 line 145, in _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "C:\my-venv\lib\site-packages\django\db\migrations\executor.py",
 line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "C:\my-venv\lib\site-packages\django\db\migrations\migration.py",
 line 129, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "C:\my-venv\lib\site-
 packages\django\db\migrations\operations\fields.py", line 147, in
 database_forwards
 schema_editor.remove_field(from_model,
 from_model._meta.get_field(self.name))
   File "C:\my-venv\lib\site-
 packages\django\db\backends\sqlite3\schema.py", line 249, in remove_field
 self._remake_table(model, delete_fields=[field])
   File "C:\my-venv\lib\site-
 packages\django\db\backends\sqlite3\schema.py", line 199, in _remake_table
 self.quote_name(model._meta.db_table),
   File "C:\my-venv\lib\site-packages\django\db\backends\base\schema.py",
 line 112, in execute
 cursor.execute(sql, params)
   File "C:\my-venv\lib\site-packages\django\db\backends\utils.py", line
 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "C:\my-venv\lib\site-packages\django\db\backends\utils.py", line
 64, in execute
 return self.cursor.execute(sql, params)
   File "C:\my-venv\lib\site-packages\django\db\utils.py", line 94, in
 __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "C:\my-venv\lib\site-packages\django\utils\six.py", line 685, in

Re: [Django] #27929: Add an option when collecting statics to remove non-cached files after processing

2017-03-14 Thread Django

#27929: Add an option when collecting statics to remove non-cached files after
processing
-+
 Reporter:  Jesse|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.10
 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


Comment:

 I think it's okay, see ticket:24452#comment:17 and subsequent comments for
 possibly related discussion.

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

Re: [Django] #27834: Add the STRPOS database function

2017-03-14 Thread Django

#27834: Add the STRPOS database function
-+-
 Reporter:  Baptiste Mispelon|Owner:  Brad
 |  Melin
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  expressions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"b625907a79bb1336cbc54231bdf7cace25fecaf7" b625907a]:
 {{{
 #!CommitTicketReference repository=""
 revision="b625907a79bb1336cbc54231bdf7cace25fecaf7"
 Fixed #27834 -- Added StrIndex database function.
 }}}

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

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

2017-03-14 Thread Django

#27936: Add some clarifications to "Spanning multi-valued relationships"
--+
 Reporter:  Thomas Güttler|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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):

 I don't think there would be consensus to use ASCII art in the Django
 documentation. If you think some diagram might be helpful (even though
 Josh said he didn't think the diagram is the right way to clarify the
 situation), please follow the pattern used by
 [https://docs.djangoproject.com/en/dev/_images/triage_process.svg existing
 images]. For simplicity, I retitled this ticket rather than closing it and
 creating a new one.

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

Re: [Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

2017-03-14 Thread Django

Comment (by Tim Graham):

I'm wondering if there should be some release notes and documentation
about this considering that it sort of looks like a bug to the untrained
eye. Should there really be multiple versions of some admin CSS files that
differ only in their hash (base.css, fonts.css, widgets.css)? Only
forms.css has different hashed files with difference contents. If a
project is uploading static files to some remote storage, the increased
disk usage and upload time due to the increased number of files could be a
nuisance.

About "the manifest lists the final filename and any intermediates could
be dropped." -- is a ticket needed for this enhancement?

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

Re: [Django] #27926: Allow squashmigrations to create a fresh set of migrations and delete the old ones (was: Squashmigrations --hard)

2017-03-14 Thread Django

#27926: Allow squashmigrations to create a fresh set of migrations and delete 
the
old ones
-+-
 Reporter:  Pascal Briet |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  squashmigrations | Triage Stage:
 |  Someday/Maybe
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 => Someday/Maybe


Comment:

 It seems a discussion on the DevelopersMailingList would be useful to find
 consensus about how to proceed here.

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

2017-03-14 Thread Django

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  1.11
 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:

 Thanks Simon. I created a [https://github.com/django/django/pull/8178 PR]
 with your suggestion.

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

Re: [Django] #27939: GeoDjango - map doesn't show correct point in admin

2017-03-14 Thread Django

#27939: GeoDjango - map doesn't show correct point in admin
-+-
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  gis, geodjango,  | Triage Stage:  Accepted
  map, admin |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Ah yes, the new base layer from vis.earthdata.nasa.gov is also in the 3857
 projection, and not 4326 as the previous one.
 Before GDAL was required, we required that the projection of the default
 base layer was 4326 so that no coordinates conversion were required to
 display geometries in the default SRID. Now I think we can simply set the
 `OpenLayersWidget.map_srid` to 3857 to fix this issue.

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

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

Re: [Django] #27939: GeoDjango - map doesn't show correct point in admin

2017-03-14 Thread Django

#27939: GeoDjango - map doesn't show correct point in admin
-+-
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  gis, geodjango,  | Triage Stage:  Accepted
  map, admin |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * severity:  Normal => Release blocker


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

Re: [Django] #27920: RadioSelect is not rendering the value attribute when it is empty

2017-03-14 Thread Django

#27920: RadioSelect is not rendering the value attribute when it is empty
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"70c5b8db4213e9556fcdd7967d042d81f06ddad8" 70c5b8db]:
 {{{
 #!CommitTicketReference repository=""
 revision="70c5b8db4213e9556fcdd7967d042d81f06ddad8"
 [1.11.x] Refs #27920 -- Added missing encoding preamble on widget test
 file
 }}}

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

Re: [Django] #27939: GeoDjango - map doesn't show correct point in admin

2017-03-14 Thread Django

#27939: GeoDjango - map doesn't show correct point in admin
-+-
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  gis, geodjango,  | Triage Stage:  Accepted
  map, admin |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * stage:  Unreviewed => Accepted


Comment:

 It looks like map widget expects coordinates in the different SRID.

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

Re: [Django] #27920: RadioSelect is not rendering the value attribute when it is empty

2017-03-14 Thread Django

#27920: RadioSelect is not rendering the value attribute when it is empty
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"d8e90040e904fe64586bedaae3332244506563f6" d8e90040]:
 {{{
 #!CommitTicketReference repository=""
 revision="d8e90040e904fe64586bedaae3332244506563f6"
 [1.11.x] Fixed #27920 -- Restored empty RadioSelect choice producing
 value=""

 Regression in b52c73008a9d67e9ddbb841872dc15cdd3d6ee01.
 Thanks Tim Graham for the review.
 Backport of 540ae68a5cc6339c72375fad9b04dc48f3af4c93 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.49117c7a5da27788703bda8d27598b69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27939: GeoDjango - map doesn't show correct point in admin

2017-03-14 Thread Django

#27939: GeoDjango - map doesn't show correct point in admin
-+-
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  gis, geodjango,  | Triage Stage:
  map, admin |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by elky:

Old description:

> Just upgraded up to 1.11 and there is bug with in with gis app - map
> always displays 0,0 point in admin interface despite my object has
> correct coords.

New description:

 Just upgraded up to 1.11 and there is bug in GIS app - map always displays
 0,0 point in admin interface despite my object has correct coords.

--

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

Re: [Django] #27939: GeoDjango - map doesn't show correct point in admin

2017-03-14 Thread Django

#27939: GeoDjango - map doesn't show correct point in admin
-+-
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  gis, geodjango,  | Triage Stage:
  map, admin |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by elky):

 * Attachment "Screenshot-2017-03-14-at-22.22.17.jpg" added.

 Screenshot

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

Re: [Django] #27920: RadioSelect is not rendering the value attribute when it is empty

2017-03-14 Thread Django

#27920: RadioSelect is not rendering the value attribute when it is empty
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"540ae68a5cc6339c72375fad9b04dc48f3af4c93" 540ae68]:
 {{{
 #!CommitTicketReference repository=""
 revision="540ae68a5cc6339c72375fad9b04dc48f3af4c93"
 Fixed #27920 -- Restored empty RadioSelect choice producing value=""

 Regression in b52c73008a9d67e9ddbb841872dc15cdd3d6ee01.
 Thanks Tim Graham for the review.
 }}}

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

[Django] #27939: GeoDjango - map doesn't show correct point in admin

2017-03-14 Thread Django

#27939: GeoDjango - map doesn't show correct point in admin
-+-
   Reporter:  elky   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  GIS|Version:  1.11
   Severity:  Normal |   Keywords:  gis, geodjango,
   Triage Stage: |  map, admin
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Just upgraded up to 1.11 and there is bug with in with gis app - map
 always displays 0,0 point in admin interface despite my object has correct
 coords.

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

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

2017-03-14 Thread Django

Comment (by Thomas Güttler):

Replying to [comment:1 Josh Smeaton]:
> I think there's definitely scope to improve the docs around multi valued
relationships, but I don't think ASCII art (or that diagram) is really the
right way of doing it. For some added confusion, the docs fail to mention
that duplicates are possible with the second query (with multiple filters)
if there is an entry with the headline Lennon AND it was posted in 2008.
It seems the docs go through a lot of effort to avoid mentioning that a
second filter causes the query to create a second join to the same table.

Hi Josh,

I think your proposal to change the docs are valid.

This issue is about the ascii art.

Why not open a new issue for your proposal?

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

Re: [Django] #27938: Warning in tests: UserWarning: Limit for query logging exceeded, only the last 9000 queries will be returned.

2017-03-14 Thread Django

#27938: Warning in tests: UserWarning: Limit for query logging exceeded, only 
the
last 9000 queries will be returned.
---+--
 Reporter:  Pavel Patrin   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.10
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 Duplicate of #27539.

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

[Django] #27938: Warning in tests: UserWarning: Limit for query logging exceeded, only the last 9000 queries will be returned.

2017-03-14 Thread Django

#27938: Warning in tests: UserWarning: Limit for query logging exceeded, only 
the
last 9000 queries will be returned.
-+
   Reporter:  Pavel Patrin   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Testing framework  |Version:  1.10
   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 got a warning in test enviromnent.

 `django/db/backends/base/base.py:133: UserWarning: Limit for query logging
 exceeded, only the last 9000 queries will be returned.`

 After it assertion `assertNumQueries()` always fails with '0 != XXX
 queries'.

 As a hotfix I close all opened connections and do `del
 connections[conname]` in `TestCase.tearDownClass()`.

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

2017-03-14 Thread Django

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  1.11
 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 Simon Charette):

 It looks like something is wrong with
 
[https://github.com/django/django/blob/e7033e00f8e1ba2ffe538e56c5088a7e94c2e45d/django/forms/models.py#L1158
 ModelChoiceField.__deepcopy__()], it should be assigning
 `self.queryset.all()` to make sure `_result_cache` isn't shared between
 instances.

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

Re: [Django] #27914: makemigrations produces incorrect path for inner classes (was: makemigrations produces incorrect path for subclasses of Field which are inner classes)

2017-03-14 Thread Django

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:
 |  ChillarAnand
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  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 Simon Charette):

 * needs_better_patch:  0 => 1


Comment:

 I think we should focus on using `__qualname__`  during migration
 serialization as well instead of simply solving the field subclasses 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/063.3c9915956ee6ecbf0b371bf80c282a80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26709: Add operation for creating database indexes and class based indexes

2017-03-14 Thread Django

#26709: Add operation for creating database indexes and class based indexes
---+
 Reporter:  Akshesh Doshi  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  db-indexes | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Markus Holtermann ):

 In [changeset:"c654ead8988d05349e34b63e40dc1e42f9f2c2b9" c654ead8]:
 {{{
 #!CommitTicketReference repository=""
 revision="c654ead8988d05349e34b63e40dc1e42f9f2c2b9"
 [1.11.x] Used constant instead of hard-coded value for max index name
 length

 Refs #26709

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

Re: [Django] #26709: Add operation for creating database indexes and class based indexes

2017-03-14 Thread Django

#26709: Add operation for creating database indexes and class based indexes
---+
 Reporter:  Akshesh Doshi  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  db-indexes | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Markus Holtermann ):

 In [changeset:"e7033e00f8e1ba2ffe538e56c5088a7e94c2e45d" e7033e0]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7033e00f8e1ba2ffe538e56c5088a7e94c2e45d"
 Used constant instead of hard-coded value for max index name length

 Refs #26709
 }}}

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

Re: [Django] #27937: Potential issue with field.queryset._result_cache persisting

2017-03-14 Thread Django

#27937: Potential issue with field.queryset._result_cache persisting
---+--
 Reporter:  Luke Benstead  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.11
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 It's a regression in 6abd6c598ea23e0a962c87b0075aa2f79f9ead36 (#27563).
 I've reopened that ticket. Thanks for testing and reporting!

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

2017-03-14 Thread Django

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  1.11
 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):

 * status:  closed => new
 * severity:  Normal => Release blocker
 * version:  master => 1.11
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * stage:  Ready for checkin => Accepted


Comment:

 Reopening per the regression reported in #27937.

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

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships" (was: ASCII Art for docs "Spanning multi-valued relationships")

2017-03-14 Thread Django

#27936: Add some clarifications to "Spanning multi-valued relationships"
--+
 Reporter:  Thomas Güttler|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * 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/065.81201b1ca0e397cd29be49e0476875f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27937: Potential issue with field.queryset._result_cache persisting

2017-03-14 Thread Django

#27937: Potential issue with field.queryset._result_cache persisting
---+--
 Reporter:  Luke Benstead  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.11
 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 Luke Benstead):

 Unfortunately I don't have time to look into this too much, but I've
 attached a patch which updates the tests to check for an empty
 _result_cache after form instantiation. You can see that only one of the
 two tests fails (depending on order) because the _result_cache persists
 across tests.

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

Re: [Django] #27937: Potential issue with field.queryset._result_cache persisting

2017-03-14 Thread Django

#27937: Potential issue with field.queryset._result_cache persisting
---+--
 Reporter:  Luke Benstead  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.11
 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 Luke Benstead):

 * Attachment "0001-Demonstrate-that-queryset_result_cache-persists-
 ac.patch" 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/064.46b1f6c51a4fe0779cac8af95bd7f29f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27931: Clarify the meaning of "django catch-all logger"

2017-03-14 Thread Django

#27931: Clarify the meaning of "django catch-all logger"
-+-
 Reporter:  Jesse|Owner:  Vedran
 Type:   |  Karačić
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Vedran Karačić):

 * cc: vedran@… (added)
 * status:  new => assigned
 * owner:  nobody => Vedran Karačić


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

Re: [Django] #27914: makemigrations produces incorrect path for subclasses of Field which are inner classes

2017-03-14 Thread Django

#27914: makemigrations produces incorrect path for subclasses of Field which are
inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:
 |  ChillarAnand
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  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 ChillarAnand):

 * cc: anand21nanda@… (added)
 * has_patch:  0 => 1


Comment:

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

Re: [Django] #27931: Clarify the meaning of "django catch-all logger" (was: Minimum console logging level for DEBUG=True is too high)

2017-03-14 Thread Django

#27931: Clarify the meaning of "django catch-all logger"
--+
 Reporter:  Jesse |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 This looks like a misunderstanding of how logging works. "The django
 catch-all logger" only processes messages in the "django" namespace. For
 example, this will log the message:
 {{{
 import logging
 logger = logging.getLogger('django')
 logger.info("info")
 }}}
 It's not the Django's documentation to do a comprehensive explanation of
 Python logging, but some improvement might be possible.

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

Re: [Django] #27937: Potential issue with field.queryset._result_cache persisting

2017-03-14 Thread Django

#27937: Potential issue with field.queryset._result_cache persisting
---+--
 Reporter:  Luke Benstead  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.11
 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):

 Could you bisect to find the Django commit where the behavior changed? If
 you could provide some code that reproduces the issue without having to
 setup the Djangae test suite, that would be great.

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

Re: [Django] #27937: Potential issue with field.queryset._result_cache persisting

2017-03-14 Thread Django

#27937: Potential issue with field.queryset._result_cache persisting
---+--
 Reporter:  Luke Benstead  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Luke Benstead:

Old description:

> Hi,
>
> I'm currently working on porting Djangae to work with Django 1.11. As
> part of our test suite we run a number of Django tests which occasionally
> show up assumptions in the tests which don't hold true on the Google App
> Engine datastore, one common one is that IDs of objects created in tests
> will be sequential.
>
> The last remaining test failure I have is a sporadic failure in
> `tests.model_forms.tests.LimitChoicesToTests` depending on the order in
> which the tests are run, either
> `test_limit_choices_to_callable_for_fk_rel` or
> `test_limit_choices_to_callable_for_m2m_rel` fails.
>
> Here's one of those tests:
>
> def test_limit_choices_to_callable_for_fk_rel(self):
> """
> A ForeignKey can use limit_choices_to as a callable (#2554).
> """
> stumpjokeform = StumpJokeForm()
> self.assertSequenceEqual(stumpjokeform.fields['most_recently_fooled'].queryset,
> [self.threepwood])
>
> The reason for the failure, is that immediately after `StumpJokeForm()`
> is instantiated (by the second of the two tests) the field's
> `queryset._result_cache` is already populated, holding an instance which
> no longer exists in the database as it was flushed between tests. It's as
> if the field's queryset is persisting between form instantiations, and
> between tests. It looks likely that this wouldn't show up in a normal
> Django test run because IDs are sequential there and so the IDs match
> when testing the assertion.
>
> I'm always unsure about reporting bugs like this because Djangae has to
> do so much "weird" stuff to work it's possible it's something that we're
> doing but in this case I don't think it is. If it is something we're
> doing then I apologise in advance :)

New description:

 Hi,

 I'm currently working on porting Djangae to work with Django 1.11. As part
 of our test suite we run a number of Django tests which occasionally show
 up assumptions in the tests which don't hold true on the Google App Engine
 datastore, one common one is that IDs of objects created in tests will be
 sequential.

 The last remaining test failure I have is a sporadic failure in
 `tests.model_forms.tests.LimitChoicesToTests` depending on the order in
 which the tests are run, either
 `test_limit_choices_to_callable_for_fk_rel` or
 `test_limit_choices_to_callable_for_m2m_rel` fails.

 Here's one of those tests:

 {{{
 def test_limit_choices_to_callable_for_fk_rel(self):
 """
 A ForeignKey can use limit_choices_to as a callable (#2554).
 """
 stumpjokeform = StumpJokeForm()
 self.assertSequenceEqual(stumpjokeform.fields['most_recently_fooled'].queryset,
 [self.threepwood])
 }}}

 The reason for the failure, is that immediately after `StumpJokeForm()` is
 instantiated (by the second of the two tests) the field's
 `queryset._result_cache` is already populated, holding an instance which
 no longer exists in the database as it was flushed between tests. It's as
 if the field's queryset is persisting between form instantiations, and
 between tests. It looks likely that this wouldn't show up in a normal
 Django test run because IDs are sequential there and so the IDs match when
 testing the assertion.

 I'm always unsure about reporting bugs like this because Djangae has to do
 so much "weird" stuff to work it's possible it's something that we're
 doing but in this case I don't think it is. If it is something we're doing
 then I apologise in advance :)

--

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

[Django] #27937: Potential issue with field.queryset._result_cache persisting

2017-03-14 Thread Django

I'm currently working on porting Djangae to work with Django 1.11. As part
of our test suite we run a number of Django tests which occasionally show
up assumptions in the tests which don't hold true on the Google App Engine
datastore, one common one is that IDs of objects created in tests will be
sequential.

The last remaining test failure I have is a sporadic failure in
`tests.model_forms.tests.LimitChoicesToTests` depending on the order in
which the tests are run, either
`test_limit_choices_to_callable_for_fk_rel` or
`test_limit_choices_to_callable_for_m2m_rel` fails.

Here's one of those tests:

def test_limit_choices_to_callable_for_fk_rel(self):
"""
A ForeignKey can use limit_choices_to as a callable (#2554).
"""
stumpjokeform = StumpJokeForm()
self.assertSequenceEqual(stumpjokeform.fields['most_recently_fooled'].queryset,
[self.threepwood])

The reason for the failure, is that immediately after `StumpJokeForm()` is
instantiated (by the second of the two tests) the field's
`queryset._result_cache` is already populated, holding an instance which
no longer exists in the database as it was flushed between tests. It's as
if the field's queryset is persisting between form instantiations, and
between tests. It looks likely that this wouldn't show up in a normal
Django test run because IDs are sequential there and so the IDs match when
testing the assertion.

I'm always unsure about reporting bugs like this because Djangae has to do
so much "weird" stuff to work it's possible it's something that we're
doing but in this case I don't think it is. If it is something we're doing
then I apologise in advance :)

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

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

Re: [Django] #27936: ASCII Art for docs "Spanning multi-valued relationships"

2017-03-14 Thread Django

#27936: ASCII Art for docs "Spanning multi-valued relationships"
+--
 Reporter:  Thomas Güttler  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Documentation   |  Version:  1.10
 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 TZanke):

 * cc: tzanke@… (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/065.0d877fd2f7f7b6e313e8fb449c9476d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27936: ASCII Art for docs "Spanning multi-valued relationships"

2017-03-14 Thread Django

#27936: ASCII Art for docs "Spanning multi-valued relationships"
+--
 Reporter:  Thomas Güttler  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Documentation   |  Version:  1.10
 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 Smeaton):

 I think there's definitely scope to improve the docs around multi valued
 relationships, but I don't think ASCII art (or that diagram) is really the
 right way of doing it. For some added confusion, the docs fail to mention
 that duplicates are possible with the second query (with multiple filters)
 if there is an entry with the headline Lennon AND it was posted in 2008.
 It seems the docs go through a lot of effort to avoid mentioning that a
 second filter causes the query to create a second join to the same table.

 I'm not proposing new language for this myself, but I've seen many an
 experienced developer get caught by this without understanding what was
 actually happening with the underlying query. I'd very much like to see
 these docs improved in some way.

 Here's some shell output for those curious about what's happening:

 {{{

 In [1]: from datetime import date
 In [2]: d2008 = date(2008, 6, 6)
 In [3]: d2009 = date(2009, 6, 6)
 In [4]: both = Blog.objects.create(name='Match Both')

 In [5]: Entry.objects.create(blog=both, headline='1 Lennon 1',
 body_text='body', pub_date=d2008)
 Out[5]: 

 In [6]: Entry.objects.create(blog=both, headline='2 Lennon 2',
 body_text='body', pub_date=d2009)
 Out[6]: 

 In [7]: Entry.objects.create(blog=both, headline='3 Blah 3',
 body_text='body', pub_date=d2008)
 Out[7]: 

 In [8]: Blog.objects.filter(entry__headline__contains='Lennon',
 entry__pub_date__year=2008)
 Out[8]: ]>

 In [9]: justdate = Blog.objects.create(name='Match Date Only')

 In [10]: Entry.objects.create(blog=justdate, headline='4 Blah 4',
 body_text='body', pub_date=d2008)
 Out[10]: 

 In [11]: justheadline = Blog.objects.create(name='Match Headline Only')

 In [12]: Entry.objects.create(blog=justheadline, headline='5 Lennon 5',
 body_text='body', pub_date=d2009)
 Out[12]: 

 In [13]: Blog.objects.filter(entry__headline__contains='Lennon',
 entry__pub_date__year=2008)
 Out[13]: ]>

 In [14]:
 
Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)
 Out[14]: , , , ]>

 }}}

 And the queries:

 {{{

 # Blog.objects.filter(entry__headline__contains='Lennon',
 entry__pub_date__year=2008)

 SELECT
   "scratch_blog"."id",
   "scratch_blog"."name",
   "scratch_blog"."tagline"
 FROM "scratch_blog"
   INNER JOIN "scratch_entry" ON ("scratch_blog"."id" =
 "scratch_entry"."blog_id")
 WHERE (
   "scratch_entry"."pub_date" BETWEEN '2008-01-01' :: DATE AND '2008-12-31'
 :: DATE)
   AND "scratch_entry"."headline" LIKE '%Lennon%'
 );


 #
 
Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)

 SELECT
   "scratch_blog"."id",
   "scratch_blog"."name",
   "scratch_blog"."tagline"
 FROM "scratch_blog"
   INNER JOIN "scratch_entry" ON ("scratch_blog"."id" =
 "scratch_entry"."blog_id")
   INNER JOIN "scratch_entry" T3 ON ("scratch_blog"."id" = T3."blog_id")
 WHERE (
 "scratch_entry"."headline" LIKE '%Lennon%'
 AND T3."pub_date" BETWEEN '2008-01-01'::date AND '2008-12-31'::Date)
 }}}

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

Re: [Django] #27931: Minimum console logging level for DEBUG=True is too high

2017-03-14 Thread Django

#27931: Minimum console logging level for DEBUG=True is too high
---+--
 Reporter:  Jesse  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Paweł Adamczak):

 Is it considered a documentation error/typo, or is documentation correct
 here and the code should be updated to reflect 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/067.c0350c08f4c2294742857b64354263d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23425: Hide oracle specific GIS behaviour behind a feature flag

2017-03-14 Thread Django

#23425: Hide oracle specific GIS behaviour behind a feature flag
--+
 Reporter:  Josh Smeaton  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Sergey Fedoseev):

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


Comment:

 `git grep ops.oracle` gives no results, so this ticket doesn't seem to be
 actual anymore.

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

[Django] #27936: ASCII Art for docs "Spanning multi-valued relationships"

2017-03-14 Thread Django

#27936: ASCII Art for docs "Spanning multi-valued relationships"
--+
   Reporter:  Thomas Güttler  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Documentation   |Version:  1.10
   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   |
--+
 First of all: Thank you for the great docs.
 Since it took some time until we got the difference:

  {{{
 filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)

  vs

 filter(entry__headline__contains='Lennon', entry__pub_date__year=2008)
 }}}

 The docs are great:

 https://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships

 But maybe the ascii art below helps to understand it better?

 What do you think?

 {{{
   ++
   |   Lennon   |
 - |  Entry 1   |
 +---+  /  |   2008 |
 |   | /   ++
 | Blog 1|/
 filter(entry__headline__contains='Lennon', entry__pub_date__year=2008)
 |   |\   -
 +---+ \ -
\  ++
 \ ||
  -|  Entry 2   |
   ||
   ++


   ++
   |   Lennon   |
 - |  Entry 3   |
 +---+  /  ||
 |   | /   ++
 | Blog 2|/
 filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)
 |   |\
 +---+ \ -
\  ++
 \ |   2008 |
  -|  Entry 4   |
   ||
   ++
 }}}

 Ascii Art: https://textik.com/#100375b764993664

 The ascii art could get improved, I wanted to ask you first before
 polishing 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/050.02c91d8541077746260fce2b54974376%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25605: GIS functions don't work with left-hand-side expressions

2017-03-14 Thread Django

#25605: GIS functions don't work with left-hand-side expressions
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  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
-+-

Comment (by Sergey Fedoseev):

 I closed #27529 as a duplicate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.31e62a5311c4137f63f0ad664617d5f2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

43 matches

Mail list logo