Re: [Django] #30390: makemigrations requires default when adding non-nullable field even when there are no rows.

2019-04-20 Thread Django 
#30390: makemigrations requires default when adding non-nullable field even when
there are no rows.
-+-
 Reporter:  Neil du Toit |Owner:  Jay
 Type:   |  Welborn
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations   | Triage Stage:  Accepted
  default null   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jay Welborn):

 * owner:  nobody => Jay Welborn
 * status:  new => assigned


Comment:

 If the community wants this change, I have a preliminary patch working
 that will need tests/review.

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

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

Re: [Django] #30389: Duplicate object when ordering through a foreign key

2019-04-20 Thread Django 
#30389: Duplicate object when ordering through a foreign key
-+-
 Reporter:  Ajabep   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ordering, foreign| Triage Stage:
  key|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 > By dumping the SQL request, we observe that the ordering is translated
 by a join instruction.

 Hello Ajabep, while this might be surprising if you are not familiar with
 the ORM I'm afraid this isn't a bug; Django will translates all
 `multivaluefield__value` lookups into `LEFT JOIN` and `order_by` is not an
 exception.

 The only other way to express this query would be perform a ''subquery
 pushdown'' but it's unfortunately not possible to do it in a performant
 way of all support database backends.

 e.g.

 {{{#!sql
 SELECT "poc_team"."name"
 FROM "poc_team"
 WHERE "poc_team"."name" = 'R'
 ORDER BY (
 SELECT "poc_person"."creationtime"
 FROM "poc_person"
 WHERE "poc_team"."name" = "poc_person"."team_id"
 ORDER BY "poc_person"."creationtime" DESC
 LIMIT 1
 )
 }}}

 If you really want to order by a multi valued relation without using
 `distinct()` I suggest you manually perform the pushdown by ordering by a
 
[https://docs.djangoproject.com/en/2.2/ref/models/expressions/#django.db.models.Subquery
 Subquery expression].

 e.g.

 {{{#!python
 .order_by(
 Subquery(
 Person.objects.filter(
 team=OuterRef('pk')
 ).order_by('-creationtime').values('creationtime')
 )
 )
 }}}

 Note that you might experience performance issues on some backends (older
 versions of MySQL for example). So another alternative might be order by a
 `Max('persons__creationtime')` annotation.

 By the way please ensure
 [https://docs.djangoproject.com/en/2.2/internals/contributing/bugs-and-
 features/#reporting-bugs the problem you are encountering is a valid bug
 before submitting a ticket through this tracker]. You'll likely get a
 faster response through support channels and that'll reduce the ticket
 triaging burden of contributors, 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/064.8ae8de1894944e568657e4a93ea173b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30390: makemigrations requires default when adding non-nullable field even when there are no rows.

2019-04-20 Thread Django 
#30390: makemigrations requires default when adding non-nullable field even when
there are no rows.
-+-
 Reporter:  Neil du Toit |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations   | Triage Stage:  Accepted
  default null   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jay Welborn):

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

Re: [Django] #30390: makemigrations requires default when adding non-nullable field even when there are no rows.

2019-04-20 Thread Django 
#30390: makemigrations requires default when adding non-nullable field even when
there are no rows.
-+-
 Reporter:  Neil du Toit |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations   | Triage Stage:
  default null   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Jay Welborn):

 I have recreated this behavior. I'm not sure if there is a reason behind
 empty tables getting the same warning as populated tables.

 If this is a desired change, I can write a patch that drops the warning
 when adding a field to an empty database table.

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-20 Thread Django 
#30361: Watchman timing out when loading server
-+---
 Reporter:  Jacob Green  |Owner:  Jacob Green
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  2.2
 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 Jacob Green):

 * owner:  nobody => Jacob Green
 * status:  new => assigned
 * has_patch:  0 => 1
 * component:  Uncategorized => Utilities


Comment:

 I submitted a Pull Request, with the proposal that this be backported onto
 2.2 since it improves the functionality of a feature released as part of
 2.2

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

[Django] #30390: makemigrations requires default when adding non-nullable field even when there are no rows.

2019-04-20 Thread Django 
#30390: makemigrations requires default when adding non-nullable field even when
there are no rows.
-+-
   Reporter:  Neil du|  Owner:  nobody
  Toit   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  2.2
  Migrations |   Keywords:  makemigrations
   Severity:  Normal |  default null
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 When adding a non-nullable field to a model, and then running
 python manage.py makemigrations 
 Django will respond with the following:

 "You are trying to add a non-nullable field  to  without a
 default; we can't do that (the database needs something to populate
 existing rows).
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows with a
 null value for this column)
  2) Quit, and let me add a default in models.py
 Select an option: "

 This is quite frustrating when there are no existing rows. It requires
 more effort and, more importantly, leads to confusion about what
 migrations are doing. I frequently go back and check the database for my
 own sanity after seeing this message.

 Desired behavior:
 If there are no rows then there is no need for a default. This message
 should not be displayed and the migration should simply be run.

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

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

[Django] #30389: Duplicate object when ordering through a foreign key

2019-04-20 Thread Django 
#30389: Duplicate object when ordering through a foreign key
-+-
   Reporter:  Ajabep |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:
  layer (models, ORM)|   Keywords:  ordering, foreign
   Severity:  Normal |  key
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When we are using an ordering through a foreign key, a same object can be
 resolved several times.

 === PoC

  Models

 {{{
 #!python
 class Team(models.Model):
 name = models.CharField(max_length=255, primary_key=True)

 class Meta:
 ordering = ['-persons__creationtime']

 class Person(models.Model):
 uuid = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 creationtime = models.DateTimeField(auto_now_add=True)
 team = models.ForeignKey(Team, on_delete=models.CASCADE)

 class Meta:
 default_related_name = 'persons'
 }}}


  Query

 `Team.objects.filter(name="R")`


  Buggy result

 `, ]>`

 The same team is selected 2 times.


  Expected result

 `]>`

 Each teams (here, only 1) only 1 time.

  Small analysis

 By dumping the SQL request, we observe that the ordering is translated by
 a join instruction.

 `SELECT "poc_team"."name" FROM "poc_team" LEFT OUTER JOIN "poc_person" ON
 ("poc_team"."name" = "poc_person"."team_id") WHERE "poc_team"."name" = R
 ORDER BY "poc_person"."creationtime" DESC`

 Thus, if a `Team` object is linked to two `Person` objects, the `Team`
 will be selected 2 times. If it is linked to 3 `Person`, the `Team` will
 be selected 3 times.

 This bug occurred also when you are using listing some teams, joined by a
 ManyToMany relation.

 === Workaround, waiting a fix

 To avoid this bug, while there is no official fix, use the `distinct()`
 method:

 `Team.objects.filter(name="R").distinct()`

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

Re: [Django] #30388: inspectdb generates W342 emitting code

2019-04-20 Thread Django 
#30388: inspectdb generates W342 emitting code
-+-
 Reporter:  Ville Skyttä |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 Ville Skyttä):

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

[Django] #30388: inspectdb generates W342 emitting code

2019-04-20 Thread Django 
#30388: inspectdb generates W342 emitting code
-+-
   Reporter:  Ville  |  Owner:  nobody
  Skyttä |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  2.2
  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  |
-+-
 inspectdb generates code that results in W342 warnings. Will attach a fix.

 No release note yet, will add one once I get information which branch this
 will be applied to.

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

Re: [Django] #30380: Support mysql query objects as strings in addition to bytes, for PyMySQL support.

2019-04-20 Thread Django 
#30380: Support mysql query objects as strings in addition to bytes, for PyMySQL
support.
-+-
 Reporter:  Nathan Klug  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

 Thanks Tobias, good catch! I added
 [https://github.com/django/django/pull/11259 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/065.544d6582adb801e79bc0ed1d21034eb6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

2019-04-20 Thread Django 
#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tomer Chachamu):

 Maybe configure the level of the 'django.utils.autoreload' logger to DEBUG
 and paste some logs here? Do you get "Watching for file changes with
 StatReloader" or "Watching for file changes with WatchmanReloader"?

 You can also run the manage.py shell and run this:

 from django.utils import autoreload
 autoreload.WatchmanReloader.check_availability()

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

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

Re: [Django] #30380: Support mysql query objects as strings in addition to bytes, for PyMySQL support.

2019-04-20 Thread Django 
#30380: Support mysql query objects as strings in addition to bytes, for PyMySQL
support.
-+-
 Reporter:  Nathan Klug  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tobias Krönke):

 Is the partial revert correct? The comment now reads

 {{{
 cursor objects have an (undocumented) "_executed"
 }}}

 but the actual code gets

 {{{
 '_last_executed'
 }}}

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