Re: [Django] #26083: Python 2 deprecation warnings for classes that define __eq__() but not __hash__()

[Django]

#26083: Python 2 deprecation warnings for classes that define __eq__() but not
__hash__()
--+
 Reporter:  atombrella|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Description changed by benf-wspdigital:

Old description:

> I ran `python -Werror runtests.py` for DRF,  and noticed quite a lot of
> warnings about `__eq__` and `__hash__`, and then checked Django's
> repository.
>
> `DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in
> 3.x`

New description:

 Many classes within Django define the `__eq__` method, which in Python 3
 will have disruptive implications for inheritance of `__hash__`. See the
 [https://docs.python.org/3.4/reference/datamodel.html#object.__hash__
 Python 3 documentation for `__hash__`]:

 If a class does not define an __eq__() method it should not define a
 __hash__() operation either; if it defines __eq__() but not __hash__(),
 its instances will not be usable as items in hashable collections. […]

 and continues on to describe in detail the implications of defining
 `__eq__` and/or `__hash__`, and exactly why one would implement one and/or
 the other on a class.

 The warning emitted by `python2 -3` for this is:

 DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__
 in 3.x

--

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

Re: [Django] #5908: Cycle tag should reset after it steps out of scope(?)

[Django]

#5908: Cycle tag should reset after it steps out of scope(?)
-+-
 Reporter:  Simon Litchfield |Owner:  sergei-
    |  maertens
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cycle templatetag| Triage Stage:  Accepted
  tag counter for loop reset |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


Comment:

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

Re: [Django] #26842: SQLite3 backend raises error when reading tz-aware datetime value

[Django]

#26842: SQLite3 backend raises error when reading tz-aware datetime value
-+-
 Reporter:  ryochiji |Owner:
 |  kennethyang404
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 kennethyang404):

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


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

Re: [Django] #26842: SQLite3 backend raises error when reading tz-aware datetime value

[Django]

#26842: SQLite3 backend raises error when reading tz-aware datetime value
-+-
 Reporter:  ryochiji |Owner:
 |  kennethyang404
 Type:  Uncategorized|   Status:  assigned
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:  1|UI/UX:  0
-+-

Comment (by kennethyang404):

 SQLite doesn't support tz-aware datetimes.

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

Re: [Django] #26843: empty_label argument on ModelChoiceField is not tested

[Django]

#26843: empty_label argument on ModelChoiceField is not tested
-+-
 Reporter:  smarlowucf   |Owner:
 Type:   |  smarlowucf
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  ModelChoiceField,Tests,empty_label |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by smarlowucf):

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

[Django] #26843: empty_label argument on ModelChoiceField is not tested

[Django]

#26843: empty_label argument on ModelChoiceField is not tested
-+-
 Reporter:  smarlowucf   |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |
Component:  Testing framework|Version:  master
 Severity:  Normal   |   Keywords:
 |  ModelChoiceField,Tests,empty_label
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 The `empty_label` attribute on `ModelChoiceField` is not tested.

 Possible cases:

 {{{
 # No empty label option
 empty_label = None

 # Changes empty label display value
 empty_label = "Select One"
 }}}

 Additionally, if the field is required and initial is not None the value
 is set to None.
 [https://github.com/django/django/blob/master/django/forms/models.py#L1137]

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

Re: [Django] #26842: SQLite3 backend raises error when reading tz-aware datetime value

[Django]

#26842: SQLite3 backend raises error when reading tz-aware datetime value
-+-
 Reporter:  ryochiji |Owner:
 |  kennethyang404
 Type:  Uncategorized|   Status:  assigned
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:  1|UI/UX:  0
-+-
Changes (by kennethyang404):

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

[Django] #26842: SQLite3 backend raises error when reading tz-aware datetime value

[Django]

#26842: SQLite3 backend raises error when reading tz-aware datetime value
--+
 Reporter:  ryochiji  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 When a DateTimeField in a sqlite3 backend contains a timezone-aware value,
 an error is raised when reading the object. This seems to happen because
 
[https://github.com/django/django/blob/stable/1.9.x/django/db/backends/sqlite3/operations.py#L215
 convert_datetimefield_value] doesn't check to make sure the value is naive
 before passing to make_aware, which
 
[https://github.com/django/django/blob/stable/1.9.x/django/utils/timezone.py#L367
 raises an error if it receives a tz-aware value].

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

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

Re: [Django] #26837: ModelMultipleChoiceField's documentation doesn't mention whether it supports to_field_name

[Django]

#26837: ModelMultipleChoiceField's documentation doesn't mention whether it
supports to_field_name
-+-
 Reporter:  bmispelon|Owner:
 Type:   |  smarlowucf
  Cleanup/optimization   |   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 smarlowucf):

 I looked into the tests for this ticket and noticed that the
 `to_field_name` argument is covered for both `ModelMultipleChoiceField`
 and `ModelChoiceField`.

 
https://github.com/django/django/blob/c9ae09addffb839403312131d4251e9d8b454508/tests/model_forms/tests.py#L2404

 However, I noticed that the `empty_label` argument is not covered for
 `ModelChoiceField`.

 Is it okay to add a test for this argument as part of this ticket or
 should a new ticket be created?

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

Re: [Django] #25995: Add more sophisticated serialization support to JSONField

[Django]

#25995: Add more sophisticated serialization support to JSONField
--+
 Reporter:  jimgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  JSONB | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by debanshuk):

 * cc: debanshuk2007@… (added)


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

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

Re: [Django] #25995: Add more sophisticated serialization support to JSONField

[Django]

#25995: Add more sophisticated serialization support to JSONField
--+
 Reporter:  jimgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  JSONB | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by debanshuk):

 We could use a custom data type representation scheme to represent dates,
 decimals etc in JSON.

 The scheme could be similar to what MongoDB uses for it's extended JSON
 (https://docs.mongodb.com/manual/reference/mongodb-extended-json/#bson-
 data-types-and-associated-representations).
 Eg: a date object would be stored as {{{ {"$date": }
 }}}

 Or,

 It could be something more sophisticated and generic like
 {{{
 {
 "$djExtJson": {
 "$type": ,
 "$args": ,
 "$kwargs": 
 }
 }
 }}}
 Where '$type' would be the full path of a class (eg, {{{ datetime.date }}}
 or {{{ decimal.Decimal }}}) and '$args' and '$kwargs' would be the
 arguments for constructor of the class.

 So a date object would be stored as:
 {{{
 {"$djExtJson": {"$type": "datetime.date", "$args": ["2016", "7", "6"]}}
 }}}

 and a decimal object as:
 {{{
 {"$djExtJson": {"$type": "decimal.Decimal", "$args": ["21.5"]}}
 }}}

 Using this format, one would be able to store any class's object in JSON.
 Eg:
 {{{
 # my_utils.py
 class ABC():
 def __init__(self, dt: date):
 self.date = dt
 }}}
 An object of above class could be stored as:
 {{{
 {"$djExtJson": {
 "$type": "my_utils.ABC",
 "$args": [{"$djExtJson": {"$type": "datetime.date", "$args": ["2016",
 "7", "6"]}}]
 }}
 }}}

 Deserialisation of objects using above format would be very simple, as we
 would have type information stored withing the object with all the
 arguments required to call constructor of that type, so we would be able
 to call the constructor and get the object.

 For serialisation, it won't be possible to get arguments which need to be
 passed to a class's constructor just by looking at a object of that class.
 So for that, we can have custom code in Django for supporting
 serialisation of common standard library objects and builtins. And for
 user defined classes, we can created a mixin (we may call it {{{
 DjExtJsonSerialisable }}}) which would simply stores arguments (and
 keyword arguments) passed to the constructor of a user defined class in
 some attribute, when a object of a class inheriting from at mixin is
 created (attribute can {{{ __dj_ext_json_data__ }}}).

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

Re: [Django] #26287: SimpleLazyObject doesn't implement __radd__

[Django]

#26287: SimpleLazyObject doesn't implement __radd__
-+
 Reporter:  kezabelle|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by debanshuk):

 * cc: debanshuk2007@… (added)


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

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

Re: [Django] #26761: Add 'help_text' property to methods in ModelAdmin.list_display

[Django]

#26761: Add 'help_text' property to methods in ModelAdmin.list_display
---+--
 Reporter:  gamesbook  |Owner:  ducdetronquito
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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 ducdetronquito):

 Hi there,

 I made some changes suggested by @profuel.
 Now the PR passes all the tests \o/

 Do not hesitate to tell me if something could be improved !

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

Re: [Django] #26837: ModelMultipleChoiceField's documentation doesn't mention whether it supports to_field_name

[Django]

#26837: ModelMultipleChoiceField's documentation doesn't mention whether it
supports to_field_name
-+-
 Reporter:  bmispelon|Owner:
 Type:   |  smarlowucf
  Cleanup/optimization   |   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
-+-
Changes (by smarlowucf):

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


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

Re: [Django] #26287: SimpleLazyObject doesn't implement __radd__

[Django]

#26287: SimpleLazyObject doesn't implement __radd__
-+
 Reporter:  kezabelle|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by debanshuk):

 Replying to [ticket:26287 kezabelle]:
 > As far as I can tell, the implementation can't just be
 > {{{
 > __radd__ = new_method_proxy(operator.radd)
 > }}}
 > because that doesn't exist, which is rubbish.
 > {{{
 > __radd__ = new_method_proxy(operator.attrgetter("__radd__"))
 > }}}
 > also won't work because types may not have that attr, and attrgetter
 doesn't supress the exception (correctly)

 Wouldn't the following code work?

 {{{
 __add__ = new_method_proxy(operator.add)
 __radd__ = new_method_proxy(lambda a, b: operator.add(b, a))
 }}}

 I have tested this and it seems to work as excepted.

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

Re: [Django] #26841: Avoid remaking tables for altering index_together and unique_together in sqlite3

[Django]

#26841: Avoid remaking tables for altering index_together and unique_together in
sqlite3
-+-
 Reporter:  akki |Owner:  akki
 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
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


Comment:

 I found that without sqlite3's
 `DatabaseSchemaEditor.alter_unique_together()`
 `schema.tests.SchemaTests.test_unique_together` failed on SQLite until
 01ec127baec38b7f8281e6eca9def40f22c9e5ad.

 I guess Markus copied the `override_uniques` pattern when he did a similar
 thing for `override_indexes` in d2202ec2d4d0477b682c6d0051f27ab4843ef89f.

 The test added in 03900a02d5fd2efd6ae98bdb9974b78146f63040 fails when
 removing `override_uniques=...` in `sqlite3/schema.py` but starts passing
 after e24e9e0438cf3ba6c557558f68587d135a85e126 so it seems okay to remove
 that instance.

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

Re: [Django] #26814: Update error message to install mysqlclient module

[Django]

#26814: Update error message to install mysqlclient module
-+-
 Reporter:  ad-m |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Fixed in [92d323ccb5239e3f04b6cb749521fffa71318923].

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

Re: [Django] #26749: Different manager for _base_manager and related descriptors

[Django]

#26749: Different manager for _base_manager and related descriptors
-+-
 Reporter:  spectras |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by spectras):

 I opened another pull request as I cannot update loic's one. It is here:
 https://github.com/django/django/pull/6889
 I'm open to all suggestions to improve 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/066.11ec306f83d4afc3f297b7180291cddc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26833: alter_field() fails to drop indexes on columns with mixed case on Oracle

[Django]

#26833: alter_field() fails to drop indexes on columns with mixed case on Oracle
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akki):

 * component:  Migrations => Database layer (models, ORM)
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #26749: Different manager for _base_manager and related descriptors

[Django]

#26749: Different manager for _base_manager and related descriptors
-+-
 Reporter:  spectras |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by spectras):

 Can do.
 I checked current tests, this corner case is not covered. I'll try to add
 that today.

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

Re: [Django] #26836: Allow applications to register links in the admin interface

[Django]

#26836: Allow applications to register links in the admin interface
---+--
 Reporter:  kedare |Owner:  nobody
 Type:  New feature|   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
---+--
Changes (by kedare):

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


Old description:

> I think it would be interesting for custom applications to register links
> in various places in the admin area.
>
> The typical example would be the admindocs module, instead of hardcoding
> it in the admin template, we could have something like
>
> {{{
> #!python
> admin.register_link(title=_('Documentation'), url=reverse('...')
> location='header_right', staff_only=True))
> }}}
>
> And a specific code in the template like :
>
> {{{
> {% for link in admin.links.header_right %}
> {{ link.title }}
> {% endfor %}
> }}}
>
> We could also add other locations (Like a new pane in the admin
> frontpage, etc.)
>
> So any application could easily add its own links.
>
> Currently, as far I a know, the only way to do this is to override the
> admin templates.

New description:

 I think it would be interesting for custom applications to register links
 in various places in the admin area.

 The typical example would be the admindocs module, instead of hardcoding
 it in the admin template, we could have something like

 {{{
 #!python
 admin.register_link(title=_('Documentation'), url=reverse('...'),
 location='header_right', staff_only=True))
 }}}

 And a specific code in the template like :

 {{{
 {% for link in admin.links.header_right %}
 {{ link.title }}
 {% endfor %}
 }}}

 We could also add other locations (Like a new pane in the admin frontpage,
 etc.)

 So any application could easily add its own links.

 Currently, as far I a know, the only way to do this is to override the
 admin templates.

--

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

Re: [Django] #26761: Add 'help_text' property to methods in ModelAdmin.list_display

[Django]

#26761: Add 'help_text' property to methods in ModelAdmin.list_display
---+--
 Reporter:  gamesbook  |Owner:  ducdetronquito
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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
---+--
Changes (by timgraham):

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

Re: [Django] #26749: Different manager for _base_manager and related descriptors

[Django]

#26749: Different manager for _base_manager and related descriptors
-+-
 Reporter:  spectras |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * type:  Uncategorized => Cleanup/optimization


Comment:

 I expect it should be, but the patch is missing a test. If you want to try
 writing one, that would be helpful.

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

Re: [Django] #26615: Changing user's email could invalidate password reset tokens

[Django]

#26615: Changing user's email could invalidate password reset tokens
--+
 Reporter:  Alex  |Owner:  rosco77
 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:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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

Re: [Django] #26831: Session serialisers should document limitations on values

[Django]

#26831: Session serialisers should document limitations on values
-+-
 Reporter:  erikr|Owner:  sadaf2605
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_docs:  1 => 0
 * has_patch:  0 => 1


Comment:

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

Re: [Django] #10686: Add class name interpolation in Meta.permissions codenames (was: 2 simple improvements to permission inheritance.)

[Django]

#10686: Add class name interpolation in Meta.permissions codenames
-+-
 Reporter:  faldridge|Owner:  sergei-
 |  maertens
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
  inheritance|
Has patch:  1|  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/067.e26b1fea9475f0999ca1112a469d1d62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26841: Avoid remaking tables for altering index_together and unique_together in sqlite3

[Django]

#26841: Avoid remaking tables for altering index_together and unique_together in
sqlite3
-+-
 Reporter:  akki |Owner:  akki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akki):

 * owner:  nobody => akki
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/6888

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

Re: [Django] #25461: Mistake in model _meta API migration guide for multi-table inheritance

[Django]

#25461: Mistake in model _meta API migration guide for multi-table inheritance
---+
 Reporter:  ad-65  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.8
 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 romgar):

 Thanks for the explanation, it makes totally sense to not add these tests
 in Django.

 Just to give you a bit of context why I wanted to create this backward-
 compatible library, I had to handle a Django upgrade from 1.4 to 1.8 on a
 big project, and I decided to make this project compatible between 1.4 and
 1.X.
 It made the whole process way easier by merging small chunks of upgrades
 (if interested, I described my strategy there:
 http://romgar.github.io/presentations/django_upgrade/).
 And I thought it could have been helpful for other people in this kind of
 situation.

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

Re: [Django] #25461: Mistake in model _meta API migration guide for multi-table inheritance

[Django]

#25461: Mistake in model _meta API migration guide for multi-table inheritance
---+
 Reporter:  ad-65  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.8
 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 romgar):

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

Re: [Django] #26789: ORM produces query with NULL instead of empty geometry

[Django]

#26789: ORM produces query with NULL instead of empty geometry
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  assigned
Component:  GIS |  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 jtiai):

 Root cause it that geometry value begin nothing is tested with clause {{{
 if not value }}}. Which in turn calls {{{ __len__ }}} on a geometry,
 having a following responses in different geometries:

 For an empty point number of coordinates is returned. In case of empty 0
 (zero) is returned (false).

 For a linestring empty tuple is returned {{{ () }}} (false)

 For an polygon empty tuple of tuple is returned {{{ ((),) }}} (true)

 For a geometry collection length of 0 (zero) is returned (false)

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

Re: [Django] #26067: Orderable ArrayAgg and StringAgg

[Django]

#26067: Orderable ArrayAgg and StringAgg
-+-
 Reporter:  fdh  |Owner:  fdh
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayAgg StringAgg   | Triage Stage:  Accepted
  ordering   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by fdh):

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

Re: [Django] #26067: Orderable ArrayAgg and StringAgg

[Django]

#26067: Orderable ArrayAgg and StringAgg
-+-
 Reporter:  fdh  |Owner:  fdh
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayAgg StringAgg   | Triage Stage:  Accepted
  ordering   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by fdh):

 As pointed out by Josh Smeaton in the mailing list
 [https://groups.google.com/forum/#!topic/django-developers/YCSDX3GApBM
 discussion]:
   Consider that any ordering added within *may* need to be contributed to
 GROUP BY, but I haven't read the documentation to say that is a
 requirement.

 In the Postgres' [https://www.postgresql.org/docs/9.5/static/functions-
 aggregate.html documentation] these aggregations are only mentioned as
 being special by meaningful difference in ordering input values:
   The aggregate functions array_agg, [...] string_agg, and xmlagg, as well
 as similar user-defined aggregate functions, produce meaningfully
 different result values depending on the order of the input values. This
 ordering is unspecified by default, but can be controlled by writing an
 ORDER BY clause within the aggregate call, as shown in Section 4.2.7.
 I don't think anything in the ORDER BY clause in the aggregation would
 have to be contributed to a GROUP BY clause in the surrounding query as
 the aggregation operation is independent of the grouping of the
 surrounding query.

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

Re: [Django] #26841: Avoid remaking tables for altering index_together and unique_together in sqlite3

[Django]

#26841: Avoid remaking tables for altering index_together and unique_together in
sqlite3
-+-
 Reporter:  akki |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Feel free to propose a pull request with the proposed changes.

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

[Django] #26841: Avoid remaking tables for altering index_together and unique_together in sqlite3

[Django]

#26841: Avoid remaking tables for altering index_together and unique_together in
sqlite3
--+
 Reporter:  akki  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently the `alter_index_together`/`alter_unique_together` methods of
 `SchemaEditor` drop and remake the whole table just to add/drop indexes
 but this doesn't seem to be required. The default methods defined in
 `base.schema` seem to do the job perfectly (in fact, more efficiently) to
 me.

 I might be missing something here but no tests fail when I remove these
 methods from `sqlite3.schema`, so we are at least missing the tests to
 show why we might need to drop and re-create the whole table just to add
 an index (or a `unique_together` constraint).

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