Re: [Django] #28915: DecimalField truncates trailing zeros in the fractional part on SQLite (was: Regression in handling of DecimalField values on SQLite in Django 2.0)

[Django]

#28915: DecimalField truncates trailing zeros in the fractional part on SQLite
-+-
 Reporter:  Raphael Michel   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Tim Graham):

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

Re: [Django] #28898: Admin check prohibits using a OneToOneField in autocomplete_fields

[Django]

#28898: Admin check prohibits using a OneToOneField in autocomplete_fields
-+-
 Reporter:  Lachlan Cannon   |Owner:  Rodrigo
 |  Pinheiro Marques de Araújo
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Release blocker  |   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:"9f39f202abea4daf37f4ad3f9e4c272fd9e4d185" 9f39f202]:
 {{{
 #!CommitTicketReference repository=""
 revision="9f39f202abea4daf37f4ad3f9e4c272fd9e4d185"
 [2.0.x] Fixed #28898 -- Corrected admin check to allow a OneToOneField in
 ModelAdmin.autocomplete_fields.

 Backport of 30a389bd7795016d7f48bcda997e5dea5116f9bb from master
 }}}

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

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

Re: [Django] #28898: Admin check prohibits using a OneToOneField in autocomplete_fields

[Django]

#28898: Admin check prohibits using a OneToOneField in autocomplete_fields
-+-
 Reporter:  Lachlan Cannon   |Owner:  Rodrigo
 |  Pinheiro Marques de Araújo
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"30a389bd7795016d7f48bcda997e5dea5116f9bb" 30a389bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="30a389bd7795016d7f48bcda997e5dea5116f9bb"
 Fixed #28898 -- Corrected admin check to allow a OneToOneField in
 ModelAdmin.autocomplete_fields.
 }}}

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

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

Re: [Django] #27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.

[Django]

#27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.
-+-
 Reporter:  Jarek Glowacki   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sql None NULL| Triage Stage:  Accepted
  transform  |
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:"10bfa876be59feec24bb6a40fa11bece808ee405" 10bfa876]:
 {{{
 #!CommitTicketReference repository=""
 revision="10bfa876be59feec24bb6a40fa11bece808ee405"
 Refs #27985 -- Reallowed using __exact=None as an alias for __isnull=True
 if a custom lookup class with lookup_name != None is registered as the
 exact lookup.

 Regression in 58da81a5a372a69f0bac801c412b57f3cce5f188 and prerequisite
 for refs #28896.
 }}}

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

Re: [Django] #28896: GeoDjango PointField fails to generate query if filtering on a NULL value

[Django]

#28896: GeoDjango PointField fails to generate query if filtering on a NULL 
value
-+-
 Reporter:  William Li   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  PointField   | Triage Stage:  Ready for
  GeoDjango  |  checkin
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:"da71e4bb086593b5ca76bf698358d27ead2cfed2" da71e4bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="da71e4bb086593b5ca76bf698358d27ead2cfed2"
 Fixed #28896 -- Reallowed filtering a queryset with GeometryField=None.

 Regression in 58da81a5a372a69f0bac801c412b57f3cce5f188.
 }}}

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

Re: [Django] #28896: GeoDjango PointField fails to generate query if filtering on a NULL value

[Django]

#28896: GeoDjango PointField fails to generate query if filtering on a NULL 
value
-+-
 Reporter:  William Li   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  PointField   | Triage Stage:  Ready for
  GeoDjango  |  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:"ce26ec01631b00f1d0062a18c79abc93c489b75d" ce26ec0]:
 {{{
 #!CommitTicketReference repository=""
 revision="ce26ec01631b00f1d0062a18c79abc93c489b75d"
 [2.0.x] Fixed #28896 -- Reallowed filtering a queryset with
 GeometryField=None.

 Regression in 58da81a5a372a69f0bac801c412b57f3cce5f188.

 Backport of da71e4bb086593b5ca76bf698358d27ead2cfed2 from master
 }}}

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

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

Re: [Django] #28896: GeoDjango PointField fails to generate query if filtering on a NULL value

[Django]

#28896: GeoDjango PointField fails to generate query if filtering on a NULL 
value
-+-
 Reporter:  William Li   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  PointField   | Triage Stage:  Ready for
  GeoDjango  |  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:"a5c60404476124c682c996bfb1eb077d59f1ec53" a5c6040]:
 {{{
 #!CommitTicketReference repository=""
 revision="a5c60404476124c682c996bfb1eb077d59f1ec53"
 [2.0.x] Refs #27985 -- Reallowed using __exact=None as an alias for
 __isnull=True if a custom lookup class with lookup_name != None is
 registered as the exact lookup.

 Regression in 58da81a5a372a69f0bac801c412b57f3cce5f188 and prerequisite
 for refs #28896.

 Backport of 10bfa876be59feec24bb6a40fa11bece808ee405 from master
 }}}

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

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

Re: [Django] #27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.

[Django]

#27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.
-+-
 Reporter:  Jarek Glowacki   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sql None NULL| Triage Stage:  Accepted
  transform  |
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:"a5c60404476124c682c996bfb1eb077d59f1ec53" a5c6040]:
 {{{
 #!CommitTicketReference repository=""
 revision="a5c60404476124c682c996bfb1eb077d59f1ec53"
 [2.0.x] Refs #27985 -- Reallowed using __exact=None as an alias for
 __isnull=True if a custom lookup class with lookup_name != None is
 registered as the exact lookup.

 Regression in 58da81a5a372a69f0bac801c412b57f3cce5f188 and prerequisite
 for refs #28896.

 Backport of 10bfa876be59feec24bb6a40fa11bece808ee405 from master
 }}}

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

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

Re: [Django] #28896: GeoDjango PointField fails to generate query if filtering on a NULL value

[Django]

#28896: GeoDjango PointField fails to generate query if filtering on a NULL 
value
-+-
 Reporter:  William Li   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  2.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  PointField   | Triage Stage:  Ready for
  GeoDjango  |  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:"10bfa876be59feec24bb6a40fa11bece808ee405" 10bfa876]:
 {{{
 #!CommitTicketReference repository=""
 revision="10bfa876be59feec24bb6a40fa11bece808ee405"
 Refs #27985 -- Reallowed using __exact=None as an alias for __isnull=True
 if a custom lookup class with lookup_name != None is registered as the
 exact lookup.

 Regression in 58da81a5a372a69f0bac801c412b57f3cce5f188 and prerequisite
 for refs #28896.
 }}}

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

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * version:  2.0 => master
 * 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.4ebce3a5a5c2efa92147ffb6c3027c86%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28911: Django dependency pytz does not recognize Msft time zone within Windows Subsystem for Linux

[Django]

#28911: Django dependency pytz does not recognize Msft time zone within Windows
Subsystem for Linux
--+--
 Reporter:  El'endia Starman  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Utilities |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  timezone  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

 * owner:  (none) => nobody
 * component:  Error reporting => Utilities
 * easy:  1 => 0


Comment:

 I don't understand the reasoning behind your proposed patch. It seems that
 will make Django silently ignore an invalid time zone and use UTC instead.
 Can you clarify? Is your use case not solved with `TIME_ZONE = 'UTC'`?

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

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

[Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
   Reporter:  Daniel |  Owner:  nobody
  Miller |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  QuerySet.extra
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 [http://django-cte-trees.readthedocs.io/en/latest/ django-cte-trees] (also
 [https://github.com/matthiask/django-cte-forest django-cte-forest])
 provides specialized uses of CTE queries for managing hierarchical data
 with recursive queries. To accomplish this, it uses the `QuerySet.extra()`
 API. This is my specific use case for CTE queries at the moment, however
 it leverages only one small part of what is possible with CTE queries:
 [https://www.postgresql.org/docs/9.6/static/queries-with.html PostgreSQL],
 [https://dev.mysql.com/doc/refman/8.0/en/with.html MySQL],
 [https://docs.microsoft.com/en-us/sql/t-sql/queries/with-common-table-
 expression-transact-sql SQL Server].

 Another implementation supporting more general uses of CTE queries was
 [https://groups.google.com/forum/#!topic/django-developers/b370mxfKCHg
 presented on the developers mailing list], although I'm not sure it has
 ever made it any further than that. The code can be found
 [https://github.com/django/django/compare/master...ashleywaite:cte-dev on
 github]. It appears to do its magic by mutating `base_query.extra_tables`,
 which seems to be a private/internal part of the 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/052.ddb8e94247cbe0aa063ff275ad8679a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26780: Prefetch objects don't work with slices

[Django]

#26780: Prefetch objects don't work with slices
-+-
 Reporter:  Ludwik Trammer   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, slicing| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jeff Johnson):

 I tried the filter by rank suggestion using Django 2.0 but I get this
 error:

 {{{
 django.db.utils.NotSupportedError: Window is disallowed in the filter
 clause.
 }}}

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

Re: [Django] #28898: Admin check prohibits using a OneToOneField in autocomplete_fields

[Django]

#28898: Admin check prohibits using a OneToOneField in autocomplete_fields
-+-
 Reporter:  Lachlan Cannon   |Owner:  Rodrigo
 |  Pinheiro Marques de Araújo
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Rodrigo Pinheiro Marques de Araújo):

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

[Django] #28918: refresh_from_db should use _base_manager

[Django]

#28918: refresh_from_db should use _base_manager
-+-
   Reporter:  Sjoerd |  Owner:  nobody
  Job Postmus|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using `refresh_from_db`, currently the `_default_manager` is used.

 Based upon the documentation at
 https://docs.djangoproject.com/en/2.0/topics/db/managers/#default-managers
 , it seems that there's a requirement for `_base_manager` to not filter
 out results, while for `_default_manager` there's just a preference for
 this to be the case.

 I think the stronger "guarantee" provided by `_base_manager` is more
 appropriate in this case.

 The following patch both adds a test and fixes the issue.

 {{{
 diff --git a/django/db/models/base.py b/django/db/models/base.py
 index 27ca63fd22..0813bedcb0 100644
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -591,7 +591,7 @@ class Model(metaclass=ModelBase):
  'are not allowed in fields.' % LOOKUP_SEP)

  db = using if using is not None else self._state.db
 -db_instance_qs =
 self.__class__._default_manager.using(db).filter(pk=self.pk)
 +db_instance_qs =
 self.__class__._base_manager.using(db).filter(pk=self.pk)

  # Use provided fields, if not set then reload all non-deferred
 fields.
  deferred_fields = self.get_deferred_fields()
 diff --git a/tests/custom_managers/tests.py
 b/tests/custom_managers/tests.py
 index ee2ac1d552..61b1a07933 100644
 --- a/tests/custom_managers/tests.py
 +++ b/tests/custom_managers/tests.py
 @@ -643,3 +643,13 @@ class CustomManagersRegressTestCase(TestCase):
  qs_custom = Person.custom_init_queryset_manager.all()
  qs_default = Person.objects.all()
  self.assertQuerysetEqual(qs_custom, qs_default)
 +
 +def test_refresh_from_db_when_default_manager_filters(self):
 +"""
 +obj.refresh_from_db() should also fetch object if default manager
 +hides it.
 +"""
 +book = Book._base_manager.create(is_published=False)
 +Book._base_manager.filter(pk=book.pk).update(title='Hi')
 +book.refresh_from_db()
 +self.assertEqual(book.title, 'Hi')
 }}}

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

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

[Django] #28917: Paginator shows ordering warning on an empty .none() queryset

[Django]

#28917: Paginator shows ordering warning on an empty .none() queryset
-+
   Reporter:  Jeremy Lainé   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Generic views  |Version:  2.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Paginator (sanely!) does a check to verify that the queryset it is passed
 is ordered, and if it isn't, shows a warning.

 However, if also emits this warning if passed a queryset which is
 guaranteed to be empty, for instance Article.objects.none()

 Working around this warning involves doing a bizarre
 Article.objects.none().order_by('id')

 I believe there can be legitimate usecases for passing a .none() queryset
 to a paginator, for instance if a user's permissions are such that we
 restrict the objects they can view to the empty queryset.

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

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

Re: [Django] #28916: Changing the type of a ForeignKey and changing unique_together creates migrations in the wrong order, causing migrations to fail

[Django]

#28916: Changing the type of a ForeignKey and changing unique_together creates
migrations in the wrong order, causing migrations to fail
+--
 Reporter:  fredley |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  migrations  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by fredley:

Old description:

> models.py before:
>

> {{{
> class MyModel(models.Model):
> fka = models.ForeignKey(SomethingA, ...)
> date = models.DateField()
>
> class Meta:
> unique_together = ('fka', 'date')
> }}}
>

> models.py after:
>

> {{{
> class MyModel(models.Model):
> fkb = models.ForeignKey(SomethingB, ...)
> date = models.DateField()
>
> class Meta:
> unique_together = ('fkb', 'date')
> }}}
>
> This can result in an automatically created migration (using `manage.py
> migrate`) that looks like this:
>
> {{{
> operations = [
> migrations.AddField(
> model_name='mymodel',
> name='fkb',
> field=models.ForeignKey(... to='myapp.somethingb'),
> ),
> migrations.RemoveField(
> model_name='mymodel',
> name='fka',
> ),
> migrations.AlterUniqueTogether(
> name='mymodel',
> unique_together={('fkb', 'date')},
> ),
> ]
> }}}
>
> This migration fails, because `AlterUniqueTogether` needs to come before
> `RemoveField`, as it references `fka`.

New description:

 models.py before:


 {{{
 class MyModel(models.Model):
 fka = models.ForeignKey(SomethingA, ...)
 date = models.DateField()

 class Meta:
 unique_together = ('fka', 'date')
 }}}


 models.py after:


 {{{
 class MyModel(models.Model):
 fkb = models.ForeignKey(SomethingB, ...)
 date = models.DateField()

 class Meta:
 unique_together = ('fkb', 'date')
 }}}

 This can result in an automatically created migration (using `manage.py
 makemigrations`) that looks like this:

 {{{
 operations = [
 migrations.AddField(
 model_name='mymodel',
 name='fkb',
 field=models.ForeignKey(... to='myapp.somethingb'),
 ),
 migrations.RemoveField(
 model_name='mymodel',
 name='fka',
 ),
 migrations.AlterUniqueTogether(
 name='mymodel',
 unique_together={('fkb', 'date')},
 ),
 ]
 }}}

 This migration fails, because `AlterUniqueTogether` needs to come before
 `RemoveField`, as it references `fka`. This is hard to debug, and can only
 be fixed by manually reordering the migration operations.

--

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

Re: [Django] #28916: Changing the type of a ForeignKey and changing unique_together creates migrations in the wrong order, causing migrations to fail

[Django]

#28916: Changing the type of a ForeignKey and changing unique_together creates
migrations in the wrong order, causing migrations to fail
+--
 Reporter:  fredley |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  migrations  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by fredley):

 * component:  Uncategorized => 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/065.086997ef6d90f9448e84fbcd3c31b087%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28916: Changing the type of a ForeignKey and changing unique_together creates migrations in the wrong order, causing migrations to fail

[Django]

#28916: Changing the type of a ForeignKey and changing unique_together creates
migrations in the wrong order, causing migrations to fail
-+
   Reporter:  fredley|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  2.0
   Severity:  Normal |   Keywords:  migrations
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 models.py before:


 {{{
 class MyModel(models.Model):
 fka = models.ForeignKey(SomethingA, ...)
 date = models.DateField()

 class Meta:
 unique_together = ('fka', 'date')
 }}}


 models.py after:


 {{{
 class MyModel(models.Model):
 fkb = models.ForeignKey(SomethingB, ...)
 date = models.DateField()

 class Meta:
 unique_together = ('fkb', 'date')
 }}}

 This can result in an automatically created migration (using `manage.py
 migrate`) that looks like this:

 {{{
 operations = [
 migrations.AddField(
 model_name='mymodel',
 name='fkb',
 field=models.ForeignKey(... to='myapp.somethingb'),
 ),
 migrations.RemoveField(
 model_name='mymodel',
 name='fka',
 ),
 migrations.AlterUniqueTogether(
 name='mymodel',
 unique_together={('fkb', 'date')},
 ),
 ]
 }}}

 This migration fails, because `AlterUniqueTogether` needs to come before
 `RemoveField`, as it references `fka`.

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

Re: [Django] #28915: Regression in handling of DecimalField values on SQLite in Django 2.0

[Django]

#28915: Regression in handling of DecimalField values on SQLite in Django 2.0
-+-
 Reporter:  Raphael Michel   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #25790: Add a way to disable column sorting in the admin

[Django]

#25790: Add a way to disable column sorting in the admin
-+-
 Reporter:  Ramiro Morales   |Owner:  Simon
 |  Charette
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sorting ordering | Triage Stage:  Accepted
  change list changelist admin   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matthijs Kooijman):

 * cc: Matthijs Kooijman (added)


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

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