Re: [Django] #26376: Explain what "searching for a list of template names" means in TemplateResponse.Mixin.get_template_names() docs.

[Django]

#26376: Explain what "searching for a list of template names" means in
TemplateResponse.Mixin.get_template_names() docs.
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.9
 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 guettli):

 Yes "The first template that is found will be used."  is more explicit
 than "searched". Thank you

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

Re: [Django] #26384: migrations fail with Python 2.7 and Django > 1.9

[Django]

#26384: migrations fail with Python 2.7 and Django > 1.9
+--
 Reporter:  brian   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.9
 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 brian):

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


Comment:

 Code that causes this failure on [https://github.com/brianmay/spud/
 github].

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

[Django] #26384: migrations fail with Python 2.7 and Django > 1.9

[Django]

#26384: migrations fail with Python 2.7 and Django > 1.9
+
 Reporter:  brian   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.9
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 With open source project called spud.

 Generates Exception:

 {{{
 FieldDoesNotExist: album has no field named u'album_id'
 }}}

 This field was removed. However in the migration that is being run when it
 fails, it did exist. So as a result, I suspect this isn't #26180.

 The migration in question attempts to rename the album_id field to id.


 Works fine with Python 3.4 or Django < =1.8


 Stack Trace:

 {{{
 /usr/lib/python2.7/dist-packages/pytest_django/fixtures.py:54: in
 _django_db_setup
 interactive=False)
 /tmp/deleteme/local/lib/python2.7/site-packages/django/test/runner.py:726:
 in setup_databases
 serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE",
 True),
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/backends/base/creation.py:70: in create_test_db
 run_syncdb=True,
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/core/management/__init__.py:119: in call_command
 return command.execute(*args, **defaults)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/core/management/base.py:399: in execute
 output = self.handle(*args, **options)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py:200: in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py:92: in migrate
 self._migrate_all_forwards(plan, full_plan, fake=fake,
 fake_initial=fake_initial)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py:121: in _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py:198: in apply_migration
 state = migration.apply(state, schema_editor)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/migrations/migration.py:123: in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/migrations/operations/fields.py:275: in
 database_forwards
 to_model._meta.get_field(self.new_name),
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py:482: in alter_field
 old_db_params, new_db_params, strict)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/backends/sqlite3/schema.py:245: in _alter_field
 self._remake_table(model, alter_fields=[(old_field, new_field)])
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/backends/sqlite3/schema.py:181: in _remake_table
 self.create_model(temp_model)
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py:250: in create_model
 to_column =
 field.remote_field.model._meta.get_field(field.remote_field.field_name).column
 }}}

 Actual error is in get_field() at

 {{{
 /tmp/deleteme/local/lib/python2.7/site-
 packages/django/db/models/options.py:582: FieldDoesNotExist
 }}}

 The migration that appears to be causing the problems (wish I could tell
 which step was failing):

 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models, migrations


 class Migration(migrations.Migration):

 dependencies = [
 ('spud', '0003_auto_20141217_0908'),
 ]

 operations = [
 migrations.AlterModelOptions(
 name='photo',
 options={'ordering': ['datetime', 'id']},
 ),
 migrations.RenameField(
 model_name='album',
 old_name='album_id',
 new_name='id',
 ),
 migrations.RenameField(
 model_name='category',
 old_name='category_id',
 new_name='id',
 ),
 migrations.RenameField(
 model_name='person',
 old_name='person_id',
 new_name='id',
 ),
 migrations.RenameField(
 model_name='photo',
 old_name='photo_id',
 new_name='id',
 ),
 migrations.RenameField(
 model_name='place',
 old_name='place_id',
 new_name='id',
 ),
 ]
 }}}

--
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

Re: [Django] #26382: Improve Storage and FileField

[Django]

#26382: Improve Storage and FileField
-+-
 Reporter:  cristianocca |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  storage filefield| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cristianocca):

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


Comment:

 I have commited to my repository a first attempt to improve this which
 seems to be working very well. No tests failed, no tests required changes
 and only one possible backwards incompatible change which might affect
 only a very limited amount of users, basically the ones that are using a
 custom Storage class, running on windows and relying on the default .save
 method of Storage. All info at the commit notes.



 
https://github.com/cristianocca/django/commit/4be936ba3031f95d34101a919648f4e8f7d7856a

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

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

Re: [Django] #26382: Improve Storage and FileField

[Django]

#26382: Improve Storage and FileField
-+-
 Reporter:  cristianocca |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  storage filefield| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cristianocca):

 * has_patch:  0 => 1


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

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

Re: [Django] #26383: Incomplete/incorrect documentation about using wsgi with Apache when project using virtualenv

[Django]

#26383: Incomplete/incorrect documentation about using wsgi with Apache when
project using virtualenv
-+-
 Reporter:  zshimanchik  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  wsgi, virtualenv,| Triage Stage:
  apache, documentation, modwsgi |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by zshimanchik):

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


Comment:

 without using python-home I've got error:

 {{{
 [Mon Mar 21 00:52:48.171727 2016] [wsgi:error] [pid 11436:tid
 140123186685696] [client 127.0.0.1:54200] mod_wsgi (pid=11436): Target
 WSGI script
 '/home/neuron/projects/django_zs_testprj/zs_testprj/zs_testprj/wsgi.py'
 cannot be loaded as Python module.
 [Mon Mar 21 00:52:48.171800 2016] [wsgi:error] [pid 11436:tid
 140123186685696] [client 127.0.0.1:54200] mod_wsgi (pid=11436): Exception
 occurred processing WSGI script
 '/home/neuron/projects/django_zs_testprj/zs_testprj/zs_testprj/wsgi.py'.
 [Mon Mar 21 00:52:48.171823 2016] [wsgi:error] [pid 11436:tid
 140123186685696] [client 127.0.0.1:54200] Traceback (most recent call
 last):
 [Mon Mar 21 00:52:48.171849 2016] [wsgi:error] [pid 11436:tid
 140123186685696] [client 127.0.0.1:54200] File
 "/home/neuron/projects/django_zs_testprj/zs_testprj/zs_testprj/wsgi.py",
 line 12, in 
 [Mon Mar 21 00:52:48.171913 2016] [wsgi:error] [pid 11436:tid
 140123186685696] [client 127.0.0.1:54200] from django.core.wsgi import
 get_wsgi_application
 [Mon Mar 21 00:52:48.171935 2016] [wsgi:error] [pid 11436:tid
 140123186685696] [client 127.0.0.1:54200] ImportError: No module named
 django.core.wsgi
 }}}
 note that I haven't installed django outside my virtualenv:
 {{{
 [neuron@eighteenth ~]$ python2 -c "import sys; print sys.path"
 ['', '/usr/lib/python2.7/site-packages/pyre-0.8_pathos-py2.7.egg',
 '/usr/lib/python2.7/site-packages/pox-0.2.2-py2.7.egg',
 '/usr/lib/python2.7/site-packages/dill-0.2.4-py2.7.egg',
 '/usr/lib/python2.7/site-packages/pp-1.5.7_pathos-py2.7.egg',
 '/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-
 linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages',
 '/usr/lib/python2.7/site-packages/gtk-2.0']
 [neuron@eighteenth ~]$ python2 -c "import django; print django"
 Traceback (most recent call last):
   File "", line 1, in 
 ImportError: No module named django
 }}}

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

[Django] #26383: Incomplete/incorrect documentation about using wsgi with Apache when project using virtualenv

[Django]

#26383: Incomplete/incorrect documentation about using wsgi with Apache when
project using virtualenv
-+-
 Reporter:  zshimanchik  |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |
Component:  Documentation|Version:  1.9
 Severity:  Normal   |   Keywords:  wsgi, virtualenv,
 |  apache, documentation, modwsgi
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 https://docs.djangoproject.com/en/1.9/howto/deployment/wsgi/modwsgi/
 I've tryied to setup apache VirtualHost for my project with virtualenv,
 using mod_wsgi in daemon mode. Project uses python2, but I think it
 doesn't matter.
 However following documentation I've tryied to use

 {{{
 WSGIDaemonProcess example.com python-
 path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
 }}}

 But this is not enough. besides python-path there must be set python-home
 with path to virtualenv directory. here is example of my working
 configuration:


 {{{
 
  ServerName site1

  WSGIDaemonProcess site1 python-
 
path=/home/neuron/projects/django_zs_testprj/zs_testprj:/home/neuron/projects/django_zs_testprj/env/lib/python2.7
 /site-packages python-home=/home/neuron/projects/django_zs_testprj/env
  WSGIProcessGroup site1
  WSGIScriptAlias /
 /home/neuron/projects/django_zs_testprj/zs_testprj/zs_testprj/wsgi.py

  
   
Require all granted
   
  
 
 }}}

 Archlinux, Python 2.7.11, Apache/2.4.18, mod_wsgi2 4.4.22-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/054.a2d1944a31318cf3c5a62ff7ef717afb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26378: Incorrect behavior in GenericIPAddressField with protocol='both', unpack_ipv4=False

[Django]

#26378: Incorrect behavior in GenericIPAddressField with protocol='both',
unpack_ipv4=False
-+-
 Reporter:  bshen|Owner:
 |  AmineYaiche
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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 AmineYaiche):

 * Attachment "26378.diff" 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/063.258003376ec62fe1084527a36b400a59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26382: Improve Storage and FileField

[Django]

#26382: Improve Storage and FileField
--+---
 Reporter:  cristianocca  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  File uploads/storage  |Version:  1.9
 Severity:  Normal|   Keywords:  storage filefield
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 Hello, following this: https://groups.google.com/forum/#!topic/django-
 developers/CjoPZq8lZms

 It seems like the Storage and FileField classes are doing too much work
 that should be actually be delegated to the storage implementation, making
 it currently a bit more complicated to implement custom storages since the
 base Storage and FileField classes perform some os dependent work and
 based on assumptions like files should be always be saved with forward
 slashes or os dependant semantics like folders and paths.

 In particular, the methods get_directory_name, get_filename and
 generate_file_name from FileField
 
(https://github.com/django/django/blob/master/django/db/models/fields/files.py#L297)
 and the method save from Storage
 (https://github.com/django/django/blob/master/django/core/files/storage.py#L57)
 should be changed a bit so they delegate their work to the actual storage
 system.

 Finally for Storage.save, the below line should be moved to the ._save
 method of FileSystemStorage

 {{{
 # Store filenames with forward slashes, even on Windows
 return force_text(name.replace('\\', '/'))
 }}}

 I would move get_directory_name, get_filename and generate_file_name to
 the Storage class, however those methods also rely on the actual instance
 and upload_to value or callable and having those parameters sent to the
 storage class might not be a good idea. I'm not sure what would be the
 best way to remove any 'os.path' usage of FileField into the actual
 storage class without breaking everything.

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

Re: [Django] #26355: Add support for PostgreSQL's array_append to ArrayField

[Django]

#26355: Add support for PostgreSQL's array_append to ArrayField
--+
 Reporter:  graup |Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  1.9
 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 pope1ni):

 I would consider expanding the scope of this somewhat...

 In the following examples, `value` is the array `[1, 2, 3]`.

 Taking this back to the simple case, the following should be supported for
 `array_append` (or the `||` operator):

 {{{
 Python: Item.objects.update(value=F('value') + 3)
 SQL:UPDATE item SET value = array_append(value, 3)
 SQL:UPDATE item SET value = value || 3
 Result: [1, 2, 3, 3]
 }}}

 In addition, the `array_cat` function or `||` operator can be used to
 concatenate arrays:

 {{{
 Python: Item.objects.update(value=F('value') + [3, 4])
 SQL:UPDATE item SET value = array_cat(value, ARRAY[3, 4])
 SQL:UPDATE item SET value = value || ARRAY[3, 4]
 Result: [1, 2, 3, 3, 4]
 }}}

 Going back to the original description, we could implement set-like
 updates to arrays (using bitwise-or):

 {{{
 Python: Item.objects.exclude(value__contains=[3]).update(value=F('value')
 + 3)
 Python: Item.objects.update(value=F('value') | 3)
 SQL:UPDATE item SET value = array_append(value, 3)
 WHERE NOT (value @> ARRAY[3]::int[])
 Result: [1, 2, 3]
 }}}

 The main challenge in all this is how to sensibly handle nested arrays.

 Also note that PostgreSQL supports assigning to indexes or slices of
 arrays - maybe this could also be added somehow:

 {{{
 Python: Item.objects.update(value__1=5)  # would need different syntax?
 SQL:UPDATE item SET value[2] = 5
 Result: [1, 5, 3]
 }}}

 {{{
 Python: Item.objects.update(value__1_2=[5])  # would need different
 syntax?
 SQL:UPDATE item SET value[2:2] = ARRAY[5]
 Result: [1, 5, 3]
 }}}

 {{{
 Python: Item.objects.update(value__1_3=[2, 1])  # would need different
 syntax?
 SQL:UPDATE item SET value[2:3] = ARRAY[2, 1]
 Result: [1, 2, 1]
 }}}

 {{{
 Python: Item.objects.update(value__1_1=[4, 5, 6])  # would need different
 syntax?
 SQL:UPDATE item SET value = value[array_lower(value, 1):1]
 || ARRAY[4, 5, 6] || value[3:array_upper(value, 1)];
 Result: [1, 4, 5, 6, 3]
 }}}

 Another consideration is for the `array_prepend` function, but I'm not
 sure how that could be handled nicely in the expressions syntax.

 We could also use `array_remove`, but this will remove all values that
 match - a bit like set difference:

 {{{
 Python: Item.objects.update(value=F('value') - 2)
 SQL:UPDATE item SET value = array_remove(value, 2)
 Result: [1, 3]
 }}}

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

Re: [Django] #26378: Incorrect behavior in GenericIPAddressField with protocol='both', unpack_ipv4=False

[Django]

#26378: Incorrect behavior in GenericIPAddressField with protocol='both',
unpack_ipv4=False
-+-
 Reporter:  bshen|Owner:
 |  AmineYaiche
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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 AmineYaiche):

 * owner:  nobody => AmineYaiche
 * status:  new => assigned
 * 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/063.5d2fb1f1d9898645d3c187888260cc89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26366: Implicitly save related models as needed instead of raising "unsaved related objects error" on Model.save()

[Django]

#26366: Implicitly save related models as needed instead of raising "unsaved
related objects error" on Model.save()
-+-
 Reporter:  aki33524 |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 aki33524):

 Replying to [comment:4 timgraham]:
 > I don't think there's much justification for making a change in Django
 here. As noted [https://code.djangoproject.com/ticket/10811#comment:5 in a
 related ticket], "Automatically saving related objects is too magic; I'm
 sure it would be considered unexpected and undesirable in some
 circumstances."
 >
 > An alternate solution in your own code is:
 > {{{
 > bar.foo.save()
 > bar.save()
 > }}}

 It doesn't work.

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

[Django] #26377: Allow migrations to specify another migration they should run before. (Kind of like `dependencies` in reverse.)

[Django]

#26377: Allow migrations to specify another migration they should run before. 
(Kind
of like `dependencies` in reverse.)
-+
 Reporter:  morganwahl   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Migrations   |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Add support for another attribute of migrations similar to `dependencies`
 that specifies other migrations this one must run before.

 I have run into two different situations where this was needed:

 - A model changes the type of it's primary key (possibly MySQL specific).
 If I have an app with a foreign key to a model in another app and that
 other app changes the type of the primary key of that model (e.g. from
 integer to string), before I can run the other app's migration that change
 the type I first have to remove the FK constraint on my model, or else the
 other migration will fail. (And then I need to add the constraint back,
 but that can be handled correctly with the `dependencies` attribute.) To
 ensure the migrations are run in the correct order, I need a way to say
 the one that removes the constraint has to run before the one that change
 the PK type. This is particularly true when the other app is not mine, but
 some package that I just use.

 - An app has a proxy model to one of it's own apps, but then decides to
 merge the proxy model into the model it subclassed. This is pretty much a
 no-op from the database's standpoint, _except_ for ContentTypes. If
 another app depends on the one with the proxy, and has a FK to
 ContentType, it needs to update the rows with FKs to the proxy's
 ContentType to be FKs to the base model's ContentType instead. This should
 run _before_ the datamigration in the proxy model's app that removes the
 ContentType, to prevent deletes cascading (or setting null or raising an
 exception, as the case may be).

 The common theme of both these situations is: an upstream model you depend
 on changes something that requires a migration of your models that must
 run before one of their migrations.

 I'm not sure how complicated this would be to implement, but it seems
 feasible.

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

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

Re: [Django] #26372: admin_order_field ignored when shadowing model field

[Django]

#26372: admin_order_field ignored when shadowing model field
---+--
 Reporter:  julianandrews  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 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 timgraham):

 Maybe it will help to give a concrete example.

 {{{  #!python
 class Foo(models.Model):
name = models.CharField()


 class FooAdmin(admin.ModelAdmin):
 list_display = ['name']

 def name(self):
 return "BLAH"
 }}}
 For this case, I see the `name` field used in `list_display` and the model
 admin method ignored.
 Therefore, I don't see the use case to define a shadow method along with
 an `admin_order_field`. Are you doing something differently?

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

Re: [Django] #25617: Disallow usernames that differ only in case in UserCreationForm

[Django]

#25617: Disallow usernames that differ only in case in UserCreationForm
--+
 Reporter:  timgraham |Owner:  nmundar
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  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 berkerpeksag):

 * cc: berker.peksag@… (added)


Comment:

 Looking at https://github.com/django/django/pull/5572 again, I'd suggest
 the following API:

 * Adding a `clean_username` method would make `UserCreationForm` less
 subclass friendly. I'd suggest rename `UserCreationForm` to
 `BaseUserCreationForm` and document it as a preferred way to extend user
 creation form
 * Add a `clean_username` method to `UserCreationForm` (it will be a
 subclass of `BaseUserCreationForm`)

 Thoughts?

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

Re: [Django] #26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value

[Django]

#26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value
--+
 Reporter:  berkerpeksag  |Owner:  berkerpeksag
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by berkerpeksag):

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


Old description:

> I noticed this while working on #25617. If you have a custom user model
> with `USERNAME_FIELD = 'email'`, you can't just subclass
> `UserCreationForm`.
>
> Here is a test case:
>
> {{{
> diff --git a/tests/auth_tests/test_forms.py
> b/tests/auth_tests/test_forms.py
> index 6172c44..1d4cd48 100644
> --- a/tests/auth_tests/test_forms.py
> +++ b/tests/auth_tests/test_forms.py
> @@ -20,7 +20,7 @@ from django.utils.encoding import force_text
>  from django.utils.text import capfirst
>  from django.utils.translation import ugettext as _
>
> -from .models.custom_user import ExtensionUser
> +from .models.custom_user import CustomUser, ExtensionUser
>  from .settings import AUTH_TEMPLATES
>

> @@ -139,6 +139,22 @@ class UserCreationFormTest(TestDataMixin, TestCase):
>  form = CustomUserCreationForm(data)
>  self.assertTrue(form.is_valid())
>
> +
> @override_settings(AUTH_MODEL='auth_tests.models.custom_user.CustomUser')
> +def test_custom_form_with_different_username_field(self):
> +class CustomUserCreationForm(UserCreationForm):
> +class Meta(UserCreationForm.Meta):
> +model = CustomUser
> +fields = ('email', 'date_of_birth')
> +
> +data = {
> +'email': 't...@client222.com',
> +'password1': 'testclient',
> +'password2': 'testclient',
> +'date_of_birth': '1988-02-24',
> +}
> +form = CustomUserCreationForm(data)
> +self.assertTrue(form.is_valid())
> +
>  def test_password_whitespace_not_stripped(self):
>  data = {
>  'username': 'testuser',
> }}}
>
> And here is the traceback:
>
> {{{
> Traceback (most recent call last):
>   File "/home/berker/projects/django/django/test/utils.py", line 208, in
> inner
> return func(*args, **kwargs)
>   File "/home/berker/projects/django/tests/auth_tests/test_forms.py",
> line 155, in test_custom_form_with_different_username_field
> form = CustomUserCreationForm(data)
>   File "/home/berker/projects/django/django/contrib/auth/forms.py", line
> 85, in __init__
> self.fields['username'].widget.attrs.update({'autofocus': ''})
> KeyError: u'username'
> }}}
>
> I will open a oull request to fix this shortly.

New description:

 I noticed this while working on #25617. If you have a custom user model
 with `USERNAME_FIELD = 'email'`, you can't just subclass
 `UserCreationForm`.

 Here is a test case:

 {{{
 diff --git a/tests/auth_tests/test_forms.py
 b/tests/auth_tests/test_forms.py
 index 6172c44..1d4cd48 100644
 --- a/tests/auth_tests/test_forms.py
 +++ b/tests/auth_tests/test_forms.py
 @@ -20,7 +20,7 @@ from django.utils.encoding import force_text
  from django.utils.text import capfirst
  from django.utils.translation import ugettext as _

 -from .models.custom_user import ExtensionUser
 +from .models.custom_user import CustomUser, ExtensionUser
  from .settings import AUTH_TEMPLATES


 @@ -139,6 +139,22 @@ class UserCreationFormTest(TestDataMixin, TestCase):
  form = CustomUserCreationForm(data)
  self.assertTrue(form.is_valid())

 +
 @override_settings(AUTH_MODEL='auth_tests.models.custom_user.CustomUser')
 +def test_custom_form_with_different_username_field(self):
 +class CustomUserCreationForm(UserCreationForm):
 +class Meta(UserCreationForm.Meta):
 +model = CustomUser
 +fields = ('email', 'date_of_birth')
 +
 +data = {
 +'email': 't...@client222.com',
 +'password1': 'testclient',
 +'password2': 'testclient',
 +'date_of_birth': '1988-02-24',
 +}
 +form = CustomUserCreationForm(data)
 +self.assertTrue(form.is_valid())
 +
  def test_password_whitespace_not_stripped(self):
  data = {
  'username': 'testuser',
 }}}

 And here is the traceback:

 {{{
 Traceback (most recent call last):
   File "/home/berker/projects/django/django/test/utils.py", line 208, in
 inner
 return func(*args, **kwargs)
   File "/home/berker/projects/django/tests/auth_tests/test_forms.py", line
 155, in test_custom_for

Re: [Django] #26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value

[Django]

#26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value
--+--
 Reporter:  berkerpeksag  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by berkerpeksag):

 * has_patch:  0 => 1


Comment:

 Pull request: https://github.com/django/django/pull/6315

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

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

Re: [Django] #26371: please add section to tutorial for switching over to and using postgres

[Django]

#26371: please add section to tutorial for switching over to and using postgres
---+--
 Reporter:  beckastar  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:  worksforme
 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 beckastar):

 * component:  Uncategorized => Documentation


Old description:

> Because it is not possible to deploy Django with SQLite, the tutorial
> would be much more complete with a section for "beyond the basics."
>
> I now have a solid understanding of the fundamentals, and have been
> struggling a lot to level up, and there are a lot of common use cases
> which are insufficiently documented.
>
> In a "beyond the basics" tutorial section, one chapter might include step
> by step instructions for moving over to Postgres using Psycopg2, and then
> using multiple settings files depending on the dev context, and
> understanding how to navigate this (honestly, I'm not even sure what
> questions to ask here, because I barely understand how it works).
>
>  It's very, very easy to make mistakes here, and the documentation for
> the psycopg2 package itself is inaccurate, and the docs for Postgres are
> overwhelming.  The combination of Django and Postgres to the new dev
> feels very, very insurmountable without a pairing buddy.  Please add docs
> to add  support for this very standard and confusing process.

New description:

 Because it is not possible to deploy Django with SQLite, the tutorial
 would be much more complete with a section for "beyond the basics."

 I now have a solid understanding of the fundamentals, and have been
 struggling a lot to level up, and there are a lot of common use cases
 which are insufficiently documented.

 In a "beyond the basics" tutorial section, one chapter might include step
 by step instructions for moving over to Postgres using Psycopg2, and then
 using multiple settings files depending on the dev context, and
 understanding how to navigate this (honestly, I'm not even sure what
 questions to ask here, because I barely understand how it works).

 ETA: correction. On some platforms, it is not possible to deploy with
 SQLite. Generally speaking, SQLite isn't the favored database for deployed
 applications.

  It's very, very easy to make mistakes here, and the documentation for the
 psycopg2 package itself is inaccurate, and the docs for Postgres are
 overwhelming.  The combination of Django and Postgres to the new dev feels
 very, very insurmountable without a pairing buddy.  Please add docs to add
 support for this very standard and confusing process.

--

Comment:

 Replying to [comment:1 claudep]:
 > Replying to [ticket:26371 beckastar]:
 > > Because it is not possible to deploy Django with SQLite, the tutorial
 would be much more complete with a section for "beyond the basics."
 >
 > Where did you read this? It is not recommended on most real deployments,
 but I'm using Django/SQLite on a very small site and I'm satisfied for
 that specific use case.
 >
 > I wouldn't say that we couldn't improve anything on this subject, but
 your description of the issue is not very targeted and I'm afraid it would
 be difficult to turn it into a real patch. It could be the subject of a
 discussion in a sprint or something like that. I'd then suggest to open a
 ticket with some proposal attached.

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

Re: [Django] #26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value

[Django]

#26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value
--+--
 Reporter:  berkerpeksag  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 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 berkerpeksag):

 * cc: berker.peksag@… (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 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/070.2c6aeb1f23511761f3f7b53b3da10012%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value

[Django]

#26381: UserCreationForm cannot be reused with a custom USERNAME_FIELD value
--+
 Reporter:  berkerpeksag  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I noticed this while working on #25617. If you have a custom user model
 with `USERNAME_FIELD = 'email'`, you can't just subclass
 `UserCreationForm`.

 Here is a test case:

 {{{
 diff --git a/tests/auth_tests/test_forms.py
 b/tests/auth_tests/test_forms.py
 index 6172c44..1d4cd48 100644
 --- a/tests/auth_tests/test_forms.py
 +++ b/tests/auth_tests/test_forms.py
 @@ -20,7 +20,7 @@ from django.utils.encoding import force_text
  from django.utils.text import capfirst
  from django.utils.translation import ugettext as _

 -from .models.custom_user import ExtensionUser
 +from .models.custom_user import CustomUser, ExtensionUser
  from .settings import AUTH_TEMPLATES


 @@ -139,6 +139,22 @@ class UserCreationFormTest(TestDataMixin, TestCase):
  form = CustomUserCreationForm(data)
  self.assertTrue(form.is_valid())

 +
 @override_settings(AUTH_MODEL='auth_tests.models.custom_user.CustomUser')
 +def test_custom_form_with_different_username_field(self):
 +class CustomUserCreationForm(UserCreationForm):
 +class Meta(UserCreationForm.Meta):
 +model = CustomUser
 +fields = ('email', 'date_of_birth')
 +
 +data = {
 +'email': 't...@client222.com',
 +'password1': 'testclient',
 +'password2': 'testclient',
 +'date_of_birth': '1988-02-24',
 +}
 +form = CustomUserCreationForm(data)
 +self.assertTrue(form.is_valid())
 +
  def test_password_whitespace_not_stripped(self):
  data = {
  'username': 'testuser',
 }}}

 And here is the traceback:

 {{{
 Traceback (most recent call last):
   File "/home/berker/projects/django/django/test/utils.py", line 208, in
 inner
 return func(*args, **kwargs)
   File "/home/berker/projects/django/tests/auth_tests/test_forms.py", line
 155, in test_custom_form_with_different_username_field
 form = CustomUserCreationForm(data)
   File "/home/berker/projects/django/django/contrib/auth/forms.py", line
 85, in __init__
 self.fields['username'].widget.attrs.update({'autofocus': ''})
 KeyError: u'username'
 }}}

 I will open a oull request to fix this shortly.

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

Re: [Django] #26265: RendererMixin id_for_label causes HTML id uniqueness violation

[Django]

#26265: RendererMixin id_for_label causes HTML id uniqueness violation
-+
 Reporter:  scoenye  |Owner:  tedmx
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.9
 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 scoenye):

 Ah. Now I see. I was looking too close in by concentrating on the
 rendering of just the field.

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

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

Re: [Django] #26366: models.Model.save() method improvement.

[Django]

#26366: models.Model.save() method improvement.
-+-
 Reporter:  aki33524 |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 aki33524):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_docs:   => 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/066.4c3563e1a4fb22576f68ed6c9a9a0356%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26364: Updating an object in a queryset with save() leads to bug using that queryset as a lookup filter

[Django]

#26364: Updating an object in a queryset with save() leads to bug using that
queryset as a lookup filter
-+-
 Reporter:  jonathan-golorry |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 jonathan-golorry):

 * type:  Uncategorized => Bug


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