Re: [Django] #30382: force_insert flag is not passed when saving parents on inherited models.

2019-04-21 Thread Django 
#30382: force_insert flag is not passed when saving parents on inherited models.
-+-
 Reporter:  Phill Tornroth   |Owner:  nobody
 Type:  Bug  |   Status:  new
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
-+-

Comment (by Phill Tornroth):

 I started working on this. As is normal, it's note quite as easy as I
 hoped. The manager .create() methods assume force_insert and there's some
 previous behavior in tests (and so presumably in the wild) where code
 might do:

 {{{
 parent = ParentModel.objects.create()
 child = ChildModel.objects.create(parent=parent)
 }}}

 The create method will pass force_insert, so the second line fails because
 it attempts to insert the parent again. A prior attempt from @akaariai
 suggested breaking this behavior (which I'm game for, if the team
 suggests). I can't think of a reasonable alternative that doesn't involve
 some other backwards-incompatible change (like making force_insert an
 explicit argument to create).

 Here's the unmerged commit from @akaraaia:
 
https://github.com/akaariai/django/commit/57384c7936fbd8d760a36c47a41ecef18e451308
 From the (effectively duplicate) ticket:
 https://code.djangoproject.com/ticket/18305

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

Re: [Django] #13910: Add generator version of Template.render(Context)

2019-04-21 Thread Django 
#13910: Add generator version of Template.render(Context)
-+
 Reporter:  Ron Panduwana|Owner:  Gagaro
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  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 Petr Glotov):

 * cc: Petr Glotov (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.36301dd21cdd30a3709eefc0f5f2c477%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

2019-04-21 Thread Django 
#30355: Specifying custom manager doesn't work with prefetch
-+-
 Reporter:  Kyle Mulka   |Owner:  robinh00d
 Type:  Bug  |   Status:  assigned
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 robinh00d):

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


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

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

2019-04-21 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 Benjamin Schollnick):

 Oh, and I just noticed, that watchman takes over 1.3 GB of memory!?!?!?

 System check identified 1 issue (0 silenced).
 April 21, 2019 - 20:33:39
 Django version 2.2, using settings 'quickbbs.settings'
 Starting development server at http://0.0.0.0:/
 Quit the server with CONTROL-C.
 Error connecting to Watchman: timed out waiting for response, while
 executing ('watch-project', '/Volumes/4TB_Drive/gallery/quickbbs')
 Watching for file changes with StatReloader

  watchman   ''**1.27 GB**'' 32  89  68350   Benjamin
 0.0 33.00   -   No  No  0 bytes 0 bytes 0
 0   0 bytes 0 bytes 64 bit  0 bytes 0 bytes 0 bytes 0 bytes No  No
 0 bytes No

 I'm sorry, but that's a insane amount of memory for a project that takes
 9.8Mb on disk.

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

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

2019-04-21 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 Benjamin Schollnick):

 Hate to say this, but can you elaborate on the django.utils.autoreload
 setting to log debug level?

 Well, I fought my way through setting up watchman, since performing

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

 Was indicating that Watchman wasn't running or was incorrectly
 configured...

 But:

 1) Ensuring Watchman is running correctly, wasn't easy, the documentation
 for Watchman isn't too fantastic
 2) Watchman at defecto "idle" is eating 2-4% of the cpu
 3) With Watchman monitoring on, I saw no significant decrease in CPU
 usage.

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

Re: [Django] #18763: Shortcut to get users by permission

2019-04-21 Thread Django 
#18763: Shortcut to get users by permission
-+-
 Reporter:  Sergiy Kuzmenko  |Owner:  Berker Peksag
 Type:  New feature  |   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 Berker Peksag):

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

Re: [Django] #30349: Using exclude on annotated FilteredRelation doesn't work

2019-04-21 Thread Django 
#30349: Using exclude on annotated FilteredRelation doesn't work
-+-
 Reporter:  Lucas Miller |Owner:  robinh00d
 Type:  Bug  |   Status:  assigned
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 Simon Charette):

 * version:  2.1 => master
 * stage:  Accepted => Ready for checkin


Comment:

 Patch looks good but it looks like doesn't qualify for a backport given
 `FilteredRelation` was introduced in Django 2.0 and isn't considered ''a
 new feature'' at this point.

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

Re: [Django] #30349: Using exclude on annotated FilteredRelation doesn't work

2019-04-21 Thread Django 
#30349: Using exclude on annotated FilteredRelation doesn't work
-+-
 Reporter:  Lucas Miller |Owner:  robinh00d
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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 robinh00d):

 * has_patch:  0 => 1


Comment:

 I've submitted a PR:
 [https://github.com/django/django/pull/11265 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/072.aabe49a6a744f477e2de80adbfca334c%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-21 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 GitHub ):

 In [changeset:"994a00eb70969e4fd8f7a30a95122e2f0411ff48" 994a00e]:
 {{{
 #!CommitTicketReference repository=""
 revision="994a00eb70969e4fd8f7a30a95122e2f0411ff48"
 Refs #30380 -- Used cursor._executed in
 DatabaseOperations.last_executed_query() on MySQL.

 Regression in a41b09266dcdd01036d59d76fe926fe0386aaade.

 Thanks Tobias Krönke for the report.
 }}}

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

Re: [Django] #30371: sqlmigrate fails with string defaults on mysql

2019-04-21 Thread Django 
#30371: sqlmigrate fails with string defaults on mysql
-+-
 Reporter:  Melvyn Sopacua   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:  regression   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 This should be fixed as a part of
 a41b09266dcdd01036d59d76fe926fe0386aaade.

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

Re: [Django] #30371: sqlmigrate fails with string defaults on mysql

2019-04-21 Thread Django 
#30371: sqlmigrate fails with string defaults on mysql
-+-
 Reporter:  Melvyn Sopacua   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:  regression   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Melvyn Sopacua):

 I think the proper fix here is to confirm both str on value and 'decode'
 attribute on quoted.

 I've tried to add a test for it, but the code never gets called anymore in
 the scope of migrations, because Django no longer transmits default values
 to the backend. So the issue is with [https://github.com/3YOURMIND/django-
 add-default-value our extension] that ensures we can do blue/green
 deployments. Looking at
 [https://github.com/PyMySQL/PyMySQL/blob/master/pymysql/converters.py this
 code] confirms your suspicions that pymysql returns strings.

 Still - when I read the code the first few times until you highlighted the
 fact here, I thought the if clause and the modification are using the same
 value, cause it's such a common pattern you don't read the variable name
 anymore.
 And secondly, it assumes that quoted has the decode() method based on a
 not related test, so I still suggest to fix it like this:


 {{{
 if isinstance(value, str) and callable(getattr(quoted, 'decode', None)):
 quoted = quoted.decode()
 }}}

 This doesn't require the performance hit of force_text and it even
 supports exotic quoted values that implement a decode() method.

-- 
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.ae0a97001aeb0c233082d4d2db124f2f%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-21 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:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 felixxm):

 * status:  assigned => closed
 * version:  2.2 => master
 * resolution:   => wontfix


Comment:

 Thanks for the report, however this is expected behavior. `makemigrations`
 cannot be based on the number of rows in the current database because in
 most of cases you will prepare migrations on one environment (e.g. dev or
 test) and run them on another (e.g. other dev, test, live etc.). Moreover
 even on the same db the number of rows can change between preparing
 migrations and running them.

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