Re: [Django] #24075: Can't migrate contenttypes and auth to zero

[Django]

#24075: Can't migrate contenttypes and auth to zero
+
 Reporter:  apollo13|Owner:  nobody
 Type:  Bug |   Status:  new
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 charettes):

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


Comment:

 The proposed patch now allows the `auth`, `contenttypes` and `sites`
 application to be migrated to any migration (zero included).

 I'm still trying to figure out how to test these changes as the test suite
 disables migrations for the `auth` and `contenttypes` application (using
 `MIGRATION_MODULES['app'] = None`).

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

Re: [Django] #23955: Documentation mentions {{ form.id }} for formsets

[Django]

#23955: Documentation mentions {{ form.id }} for formsets
-+
 Reporter:  monuszko |Owner:  you-n-g
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  formset id form  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by clairedemars1):

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


Comment:

 Hello,
 {{form.id}} is actually necessary for inline formsets (and probably also
 model formsets, but I haven't tested it)

  form.id is not displayed, but omitting it gives a MultiValueDict error
 and prevents saving when you try to save a formset having more than 1 form
 (which is the whole point of formsets)

 Sources:
 1.  personal experience
 2.  this stack exchange post http://stackoverflow.com/questions/15980475
 /multivaluedictkeyerror-in-django-modelformset-factory

 Thanks

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

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

Re: [Django] #26605: Model _default_manager can be None

[Django]

#26605: Model _default_manager can be None
+--
 Reporter:  sebdiem |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 sebdiem):

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

Re: [Django] #26605: Model _default_manager can be None

[Django]

#26605: Model _default_manager can be None
+--
 Reporter:  sebdiem |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 sebdiem):

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

[Django] #26605: Model _default_manager can be None

[Django]

#26605: Model _default_manager can be None
---+
 Reporter:  sebdiem|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 When using Model inheritance with an abstract model in between, it can
 happen that the _default_manager of the actual child class is None. In
 this case the //ModelState.from_model// function fails with the following
 error:
 {{{
 django/django/db/migrations/state.py", line 439, in from_model
 default_manager_name = force_text(model._default_manager.name)
 AttributeError: 'NoneType' object has no attribute 'name'
 }}}

 The following modified test reproduces the error:
 {{{
 @override_settings(TEST_SWAPPABLE_MODEL='migrations.SomeFakeModel')
 def test_create_swappable(self):
 """
 Tests making a ProjectState from an Apps with a swappable model
 """
 new_apps = Apps(['migrations'])

 class Base(models.Model):
 pass

 class AbstractAuthor(Base):
 class Meta:
 abstract = True

 class Author(AbstractAuthor):
 name = models.CharField(max_length=255)
 bio = models.TextField()
 age = models.IntegerField(blank=True, null=True)

 class Meta(AbstractAuthor.Meta):
 app_label = 'migrations'
 apps = new_apps
 swappable = 'TEST_SWAPPABLE_MODEL'

 author_state = ModelState.from_model(Author)
 self.assertEqual(author_state.app_label, 'migrations')
 self.assertEqual(author_state.name, 'Author')
 self.assertEqual([x for x, y in author_state.fields], ['id',
 'name', 'bio', 'age'])
 self.assertEqual(author_state.fields[1][1].max_length, 255)
 self.assertEqual(author_state.fields[2][1].null, False)
 self.assertEqual(author_state.fields[3][1].null, True)
 self.assertEqual(author_state.options, {'abstract': False,
 'swappable': 'TEST_SWAPPABLE_MODEL'})
 self.assertEqual(author_state.bases, (models.Model, ))
 self.assertEqual(author_state.managers, [])
 }}}

 Changing the following line in //ModelState.from_model//
 {{{
 if hasattr(model, "_default_manager"):
 }}}
 to
 {{{
if getattr(model, "_default_manager", None):
 }}}
 is probably sufficient to fix the 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/050.6a8b250e83161f4c28237ea62ef4881b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26596: Document {{ csrf_input }} in Jinja2 templates

[Django]

#26596: Document {{ csrf_input }} in Jinja2 templates
---+-
 Reporter:  aaugustin  |Owner:  betojulio
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 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
---+-

Comment (by betojulio):

 >{% csrf_token %} in Django templates translates to {{ csrf_input }} in
 Jinja2 templates

 This is already specified in
 https://docs.djangoproject.com/en/dev/ref/csrf/#other-template-engines

 >{{ csrf_token }} works identically in Django templates and in Jinja2
 templates
 Should I put another example in step # 2 in
 https://docs.djangoproject.com/en/dev/ref/csrf/#how-to-use-it ?, something
 like


 {{{
 
 
 
 }}}

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

Re: [Django] #24046: Deprecate the "escape" half of django.utils.safestring

[Django]

#24046: Deprecate the "escape" half of django.utils.safestring
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"60b095cc4c3dbf8bf41f7ce0939b0c90dbcc9b1a" 60b095cc]:
 {{{
 #!CommitTicketReference repository=""
 revision="60b095cc4c3dbf8bf41f7ce0939b0c90dbcc9b1a"
 Refs #24046 -- Fixed a template test when run in reverse.
 }}}

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

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

[Django]

#23919: Cleanups for when we drop Python 2 compatibility
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by timgraham:

Old description:

> This is a tracking ticket of things that we can remove when we drop
> Python 2 compatibility in Django 2.0. Please edit the description of the
> ticket as you come across new items.
>
> * `django.core.mail.message.make_msgid()` #23905
> * `django.dispatch.weakref_backports`
> * `django.http.cookie` workarounds
> * `django.utils.2to3_fixes`
> * `django.utils.decorators.ContextDecorator`
> * `django.utils.encoding`
>  * `@python_2_unicode_compatible`
>  * force/smart _unicode
>  * either force/smart _text or force/smart _str
> * `django.utils.html_parser.use_workaround`
> * `django.utils.http` functions like `urlquote_plus` -- I think the
> versions of these functions on Python 3 don't have the unicode characters
> bug we are working around.
> * `django.utils.lru_cache`
> * `django.utils.six`
> * `from __future__ import unicode_literals`
> * `str()` stuff for environment variables, e.g.
> 0bfb53866199f366ed140d49938fd185e5898156
> * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
> other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
> * `git grep 'long int'` (mostly docs)
> * `django.utils._os [npath,upath]`
> * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
> longer needed)
> * Support for pysqlite (doesn't support Python 3)
> * Replace `super(ClassName, self)` with `super()`
> * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
> default on Python 3)
> * Evaluate replacement of custom `__del__` methods by
> [https://docs.python.org/3/library/weakref.html#weakref.finalize
> weakref.finalize]
> * Remove `__ne__` from objects already defining a `__eq__`
> * Remove note about PYTHONHASHSEED (see #26243)
> * Remove Field.creation_counter (replace by metaclass `__prepare__`
> returning `OrderedDict()`,
> https://docs.python.org/3/reference/datamodel.html#preparing-the-class-
> namespace)

New description:

 This is a tracking ticket of things that we can remove when we drop Python
 2 compatibility in Django 2.0. Please edit the description of the ticket
 as you come across new items.

 * `django.core.mail.message.make_msgid()` #23905
 * `django.dispatch.weakref_backports`
 * `django.http.cookie` workarounds
 * `django.utils.2to3_fixes`
 * `django.utils.decorators.ContextDecorator`
 * `django.utils.encoding`
  * `@python_2_unicode_compatible`
  * force/smart _unicode
  * either force/smart _text or force/smart _str
 * `django.utils.html_parser.use_workaround`
 * `django.utils.http` functions like `urlquote_plus` -- I think the
 versions of these functions on Python 3 don't have the unicode characters
 bug we are working around.
 * `django.utils.lru_cache`
 * `django.utils.six`
 * `from __future__ import unicode_literals`
 * `str()` stuff for environment variables, e.g.
 0bfb53866199f366ed140d49938fd185e5898156
 * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
 other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
 * `git grep 'long int'` (mostly docs)
 * `django.utils._os [npath,upath]`
 * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
 longer needed)
 * Support for pysqlite (doesn't support Python 3)
 * Replace `super(ClassName, self)` with `super()`
 * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
 default on Python 3)
 * Evaluate replacement of custom `__del__` methods by
 [https://docs.python.org/3/library/weakref.html#weakref.finalize
 weakref.finalize]
 * Remove `__ne__` from objects already defining a `__eq__`
 * Remove note about PYTHONHASHSEED (see #26243)
 * Remove Field.creation_counter (replace by metaclass `__prepare__`
 returning `OrderedDict()`,
 https://docs.python.org/3/reference/datamodel.html#preparing-the-class-
 namespace)
 * `django.test.utils.reset_warning_registry()`

--

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

Re: [Django] #21231: Limiting the number of variables and files that a POST request can contain

[Django]

#21231: Limiting the number of variables and files that a POST request can 
contain
-+-
 Reporter:  epandurski@… |Owner:
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 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 timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #26052: Consider removing conditional_content_removal

[Django]

#26052: Consider removing conditional_content_removal
-+-
 Reporter:  aaugustin|Owner:  susan
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"baf3ec2e296a900a48181e2924753fef2e123731" baf3ec2]:
 {{{
 #!CommitTicketReference repository=""
 revision="baf3ec2e296a900a48181e2924753fef2e123731"
 Refs #26052 -- Corrected a sentence for conditional_content_removal()
 removal.
 }}}

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

Re: [Django] #24075: Can't migrate contenttypes and auth to zero

[Django]

#24075: Can't migrate contenttypes and auth to zero
+
 Reporter:  apollo13|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by charettes):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * version:  1.7 => master
 * needs_tests:  0 => 1


Comment:

 I have a mostly working [https://github.com/django/django/pull/6586 PR]
 that is still missing tests and requires some
 `MigrationExecutor.migration_plan()` tweaking that I'll try to figure out
 with the help of Markus.

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

Re: [Django] #26052: Consider removing conditional_content_removal

[Django]

#26052: Consider removing conditional_content_removal
-+-
 Reporter:  aaugustin|Owner:  susan
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Thanks for pointing that out. I think we could replace "Django will
 automatically" with "Most web servers". Did you have anything else in
 mind?

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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

[Django]

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"38c43b2a5c9e47f2fabb60521c1224825ebcc833" 38c43b2a]:
 {{{
 #!CommitTicketReference repository=""
 revision="38c43b2a5c9e47f2fabb60521c1224825ebcc833"
 Refs #24227 -- Partially reverted replacement of M2M isinstance checks by
 field.many_to_many.

 This fixes django-taggit and reflects some places where duck-typing may
 not
 be appropriate.
 }}}

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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

[Django]

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"67d984413c9540074e4fe6aa033081a35cf192bc" 67d98441]:
 {{{
 #!CommitTicketReference repository=""
 revision="67d984413c9540074e4fe6aa033081a35cf192bc"
 Refs #24227 -- Removed ManyToManyField special casing in model_to_dict().
 }}}

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

Re: [Django] #26052: Consider removing conditional_content_removal

[Django]

#26052: Consider removing conditional_content_removal
-+-
 Reporter:  aaugustin|Owner:  susan
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pope1ni):

 Tim,

 I think that some documentation might need a little rewording after this
 change:

 
https://github.com/django/django/blob/bb0b4b7/docs/topics/http/decorators.txt#L47-L52

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

Re: [Django] #26429: Name clash of merge migrations after squashing

[Django]

#26429: Name clash of merge migrations after squashing
-+-
 Reporter:  xgenadam |Owner:  rtpg
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  makemigrations   | Triage Stage:  Accepted
  merge clash|
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:"8f6a1a15516629b30e2fa2c48d5e682f7955868c" 8f6a1a15]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f6a1a15516629b30e2fa2c48d5e682f7955868c"
 Fixed #26429 -- Added a timestamp to merge migration names.

 This reduces the possibility of a naming conflict, especially after
 squashing migrations.
 }}}

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

Re: [Django] #26333: GIS geometries classes should be deconstructibles.

[Django]

#26333: GIS geometries classes should be deconstructibles.
-+-
 Reporter:  simondrabble |Owner:  niconoe
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  makemigration gis| Triage Stage:  Accepted
  point pointfield   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by niconoe):

 * has_patch:  0 => 1


Comment:

 Just created a pull request for this, testing various geometries with
 various constructors.

 Should I also write more functional tests to make sure the initial issue
 is solved (and that migration actually works with `Point`), or is testing
 that those are `deconstructible` enough?

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

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

Re: [Django] #23646: query set sql update to change different values by different keys (include django-bulk-update in core) (was: query set sql update to change different values by different keys)

[Django]

#23646: query set sql update to change different values by different keys 
(include
django-bulk-update in core)
-+-
 Reporter:  brillgen |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 brillgen):

 * version:  1.7 => 1.9


Old description:

> Database backends like Postgresql support doing multiple value update for
> the same field in different rows using a single update query. Please see
> this sample below:
>
> http://stackoverflow.com/questions/18797608/update-multiple-rows-in-same-
> query-using-postgresql
>
> Example:
> Currently:
> {{{
> Books.objects.all().update(price=10)
> }}}
>
> Proposed (syntax can vary):
> {{{
> Books.objects.all().update({'pk': 1, 'price': 10}, {'pk': 2, 'price':
> 25}])
> }}}
>
> Idea is to do it in sql for performance reasons but still use the ORM and
> not use a raw database connection.
>
> However, such an interface is not exposed via the Django ORM. Would this
> be accepted as a patch? if so, would a list dictionary with the various
> fields:values to be updated be a good way to provide the input to ORM

New description:

 **Update**
 django-bulk-upate (​https://github.com/aykut/django-bulk-update) which
 could/should be integrated into django core since we have a bulk_create
 and this corresponds well with the save (could be called bulk save if it
 makes sense). App works with an identical api to bulk_create and so should
 be a good candidate to be considered for inclusion in core.

 Database backends like Postgresql support doing multiple value update for
 the same field in different rows using a single update query. Please see
 this sample below:

 http://stackoverflow.com/questions/18797608/update-multiple-rows-in-same-
 query-using-postgresql

 Example:
 Currently:
 {{{
 Books.objects.all().update(price=10)
 }}}

 Proposed (syntax can vary):
 {{{
 Books.objects.all().update({'pk': 1, 'price': 10}, {'pk': 2, 'price':
 25}])
 }}}

 Idea is to do it in sql for performance reasons but still use the ORM and
 not use a raw database connection.

 However, such an interface is not exposed via the Django ORM. Would this
 be accepted as a patch? if so, would a list dictionary with the various
 fields:values to be updated be a good way to provide the input to ORM

--

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

Re: [Django] #23646: query set sql update to change different values by different keys

[Django]

#23646: query set sql update to change different values by different keys
-+-
 Reporter:  brillgen |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (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 brillgen):

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


Comment:

 Reopening even though it was closed by a core team member because another
 core member has reported the significant performance improvement.

 Also, there is an app called django-bulk-upate (https://github.com/aykut
 /django-bulk-update) which could/should be integrated into django core
 since we have a bulk_create and this corresponds well with the save (could
 be called bulk save if it makes sense). App works with an identical api to
 bulk_create and so should be a good candidate to be considered for
 inclusion in core.

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

Re: [Django] #26488: migrate raises InvalidBasesError if you rename a multitable inheritance base model

[Django]

#26488: migrate raises InvalidBasesError if you rename a multitable inheritance
base model
+
 Reporter:  chrisjrn|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 simonphilips):

 It seems the above solution is broken as the bases should be updated after
 renaming the model and before reloading any other models. Naively calling
 super().state_forwards() doesn't work.

 {{{
 #!python
 class RenameBaseModel(migrations.RenameModel):
 def state_forwards(self, app_label, state):
 apps = state.apps
 model = apps.get_model(app_label, self.old_name)
 model._meta.apps = apps
 # Get all of the related objects we need to repoint
 all_related_objects = (
 f for f in model._meta.get_fields(include_hidden=True)
 if f.auto_created and not f.concrete and (not f.hidden or
 f.many_to_many)
 )
 # Rename the model
 state.models[app_label, self.new_name_lower] =
 state.models[app_label, self.old_name_lower]
 state.models[app_label, self.new_name_lower].name = self.new_name
 state.remove_model(app_label, self.old_name_lower)
 # Repoint bases, this needs to be done before reloading any model
 full_old_name = "%s.%s" % (app_label, self.old_name_lower)
 full_new_name = "%s.%s" % (app_label, self.new_name_lower)
 for state_model in state.models.values():
 if full_old_name in state_model.bases:
 state_model.bases = tuple(full_new_name if b ==
 full_old_name else b
   for b in state_model.bases)
 # Repoint the FKs and M2Ms pointing to us
 for related_object in all_related_objects:
 if related_object.model is not model:
 # The model being renamed does not participate in this
 relation
 # directly. Rather, a superclass does.
 continue
 # Use the new related key for self referential related
 objects.
 if related_object.related_model == model:
 related_key = (app_label, self.new_name_lower)
 else:
 related_key = (
 related_object.related_model._meta.app_label,
 related_object.related_model._meta.model_name,
 )
 new_fields = []
 for name, field in state.models[related_key].fields:
 if name == related_object.field.name:
 field = field.clone()
 field.remote_field.model = "%s.%s" % (app_label,
 self.new_name)
 new_fields.append((name, field))
 state.models[related_key].fields = new_fields
 state.reload_model(*related_key)
 state.reload_model(app_label, self.new_name_lower)
 }}}

 Note that the migration that initially creates SubA must be run before
 this migration. If SubA is in a different app, that means you'll have to
 update that app's migration and set its `run_before` attribute.

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