Re: [Django] #30257: UsernameValidator allows trailing newline in usernames

[Django]

#30257: UsernameValidator allows trailing newline in usernames
---+---
 Reporter:  Robert Grosse  |Owner:  Ryan Schave
 Type:  Bug|   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:  1  |UI/UX:  0
---+---
Changes (by Ryan Schave):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #30270: .all() for related manager always returns empty list

[Django]

#30270: .all() for related manager always returns empty list
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  invalid
 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 Tim Graham):

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


Comment:

 I don't see an issue. `Item.objects.create(holder=holder)` populates the
 foreign key relation, not the many-to-many relation which is what
 `holder.items.count()` is querying.  You could make the test case pass
 like this (adding `holder.items.set([i1, i2])`):
 {{{ #!python
 class BugTestCase(TestCase):
 def setUp(self):
 holder = Holder.objects.create()
 i1 = Item.objects.create(holder=holder)
 i2 = Item.objects.create(holder=holder)
 holder.items.set([i1, i2])

 def test_bug(self):
 """Test bug"""
 holder = Holder.objects.get(pk=1)
 self.assertEqual(holder.items.all().count(), 2, 'Correct objects
 count')
 }}}

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

[Django] #30270: .all() for related manager always returns empty list

[Django]

#30270: .all() for related manager always returns empty list
-+-
   Reporter:  Victor |  Owner:  nobody
  Porton |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.1
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `.all()` for related manager always (at least in my case) returns empty
 list. This seems an big error or at least a wrongly documented or
 undocumented behavior.

 It is demonstrated by the attached small test project.

 The most relevant code fragment is:
 ```
 holder = Holder.objects.get(pk=1)
 self.assertEqual(holder.items.all().count(), 2, 'Correct objects
 count')
 ```

 Django 2.1.7

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

Re: [Django] #30270: .all() for related manager always returns empty list

[Django]

#30270: .all() for related manager always returns empty list
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Victor Porton):

 * Attachment "bug.tar.gz" added.

 Small project to test for the bug

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

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

Re: [Django] #30264: "OverflowError: timestamp out of range for platform time_t" test failure on 32-bit platforms

[Django]

#30264: "OverflowError: timestamp out of range for platform time_t" test 
failure on
32-bit platforms
-+-
 Reporter:  Chris Lamb   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  overflow | 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):

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

Re: [Django] #30264: "OverflowError: timestamp out of range for platform time_t" test failure on 32-bit platforms

[Django]

#30264: "OverflowError: timestamp out of range for platform time_t" test 
failure on
32-bit platforms
-+
 Reporter:  Chris Lamb   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  overflow | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #30264: "OverflowError: timestamp out of range for platform time_t" test failure on 32-bit platforms

[Django]

#30264: "OverflowError: timestamp out of range for platform time_t" test 
failure on
32-bit platforms
-+
 Reporter:  Chris Lamb   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  overflow | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

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


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

Re: [Django] #30266: Migrating a model's default primary key to a BigAutoField causes Postgres sequence to lose owner

[Django]

#30266: Migrating a model's default primary key to a BigAutoField causes 
Postgres
sequence to lose owner
-+-
 Reporter:  Dolan Antenucci  |Owner:  Dolan
 |  Antenucci
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres migration   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Dolan Antenucci):

 * owner:  nobody => Dolan Antenucci
 * status:  new => assigned


Comment:

 I have a fix, but may need help with writing my test case.. will reach out
 to mailing list if I can't figure out

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

Re: [Django] #30259: admin_order_field not working with properties

[Django]

#30259: admin_order_field not working with properties
---+
 Reporter:  Tobias Wiese   |Owner:  Jani Tiainen
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.1
 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 Jani Tiainen):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #27755: add ModelAdmin.get_inlines() hook to allow set inlines based on the request or model instance.

[Django]

#27755: add ModelAdmin.get_inlines() hook to allow set inlines based on the 
request
or model instance.
-+-
 Reporter:  WeizhongTu   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  django,admin,inlines   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  Hidde Bultsma => Hasan Ramezani
 * 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/064.f5f803d70edde3109adfe5cc6dd69453%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30269: AlterField in database_operations of SeparateDatabaseAndState migration doesn't set NOT NULL constraint for PostgreSQL

[Django]

#30269: AlterField in database_operations of SeparateDatabaseAndState migration
doesn't set NOT NULL constraint for PostgreSQL
--+--
 Reporter:  Dmitrii Prihodco  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  2.1
 Severity:  Normal|   Resolution:  invalid
 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 Simon Charette):

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


Comment:

 All the operations operate on the difference between the implicit previous
 state and the one that applying the operation on it would generate and
 `SeparateDatabaseAndState` behaves the same way.

 What you are doing here by breaking the desired changes in two migrations
 by creating an asymmetry between the project state and the database state.
 When the second operation runs the state already has it's field altered by
 the previous `SeparateDatabaseAndState` and thus the migration framework
 considers your database operation as a noop.

 In summary this is working as designed and performing the second operation
 using `RunSQL` is the right approach if you want to effectively break this
 in two migrations. A preferred way of ensuring no downtime for such field
 alteration is usually to simply run such migrations once the code is
 deployed instead.

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

[Django] #30269: AlterField in database_operations of SeparateDatabaseAndState migration doesn't set NOT NULL constraint for PostgreSQL

[Django]

#30269: AlterField in database_operations of SeparateDatabaseAndState migration
doesn't set NOT NULL constraint for PostgreSQL
--+
   Reporter:  Dmitrii |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  2.1
   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   |
--+
 For changing a field, and not having some unpredictable behavior we employ
 multi-stage deployments.

 So for example we have a field:
 {{{
 name = models.CharField(max_length=255, null=True)
 }}}

 And we want to make it non-nullable. To make it so we perform two
 migrations, firstly the state:

 {{{
 operations = [
 # Plus whatever data migration is needed for the NULL values
 migrations.SeparateDatabaseAndState(
 state_operations=[
 migrations.AlterField(
 model_name='testmodel',
 name='name',
 field=models.CharField(max_length=255)
 )
 ]
 )
 ]
 }}}

 After all parts of the system have been updated with code that handles the
 given field only in a non-nullable way, we can safely set it to NON NULL
 in the database:

 {{{
 operations = [
 migrations.SeparateDatabaseAndState(
 database_operations=[
 migrations.AlterField(
 model_name='testmodel',
 name='name',
 field=models.CharField(max_length=255)
 )
 ]
 )
 ]
 }}}

 But the last migration doesn't actually perform any changes, the field
 remains nullable in the database. This can be circumvented by using
 migrations.RunSQL, but one can easily miss out the need to do that.

 PostgreSQL in use: 9.6 official docker image.
 Originally found for Django 1.8, reproduced for Django 2.1.7.

 Didn't reproduce with SQLite.

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

Re: [Django] #30018: Regression for selenium tests & inaccurate Content-Length

[Django]

#30018: Regression for selenium tests & inaccurate Content-Length
--+
 Reporter:  Xavier Fernandez  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  2.1
 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 Pascal Wichmann):

 * cc: Pascal Wichmann (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/070.9b7b2079f37c5f9079b52b743e695be5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27801: Make createsuperuser inspect environment variables for username and password

[Django]

#27801: Make createsuperuser inspect environment variables for username and
password
-+-
 Reporter:  Markus Holtermann|Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  James Pic => Hasan Ramezani


Comment:

 @Tim Graham, do we still need this? do you prefer to read the password
 from the file or environment variable?

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

[Django] #30268: Django admin list_editable overrides changes done elsewhere

[Django]

#30268: Django admin list_editable overrides changes done elsewhere
+
   Reporter:  Brillgen Developers   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |Version:  2.1
   Severity:  Normal|   Keywords:  admin
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 If a field is made list_editable, all the objects displayed on the page
 are overridden even if they are not changed when save is pressed on the
 django admin changelist page.

 There is a way this can be handled:
 - Keep a hidden field with the original value and only save when the
 hidden field is different from the value in the form field

 This can be a option in the admin if we are worried about making the page
 heavier than it needs to be

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

Re: [Django] #28373: TIME_ZONE value in DATABASES settings is not used for date lookup

[Django]

#28373: TIME_ZONE value in DATABASES settings is not used for date lookup
-+-
 Reporter:  Victor Talpaert  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  settings ORM lookup  | Triage Stage:  Accepted
  mysql timezone |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * cc: Can Sarıgöl (added)
 * needs_tests:  1 => 0


Comment:

 hi, I have a PR to fix this part about another  problem. added a commit to
 include into it.
 
[https://github.com/django/django/pull/10910/commits/088cf0d6dec564db37d1d7754c469d1784e1740b
 Commit]

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

Re: [Django] #30240: Add support for SHA database functions.

[Django]

#30240: Add support for SHA database functions.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sha1, sha224,| Triage Stage:  Ready for
  sha256, sha384, sha512 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #25253: MySQL migrations drop & recreate constraints unnecessarily when changing attributes that don't affect the schema

[Django]

#25253: MySQL migrations drop & recreate constraints unnecessarily when changing
attributes that don't affect the schema
--+
 Reporter:  Thomas Recouvreux |Owner:  Shun Yu
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  migrations m2m mysql  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by israel-tk):

 We had this problem with Postgres and Django 1.11 when deleting a not-null
 constraint in a ForeignKey field (adding null=True to a field). Instead of
 just dropping the not-null constraint which is a safe database operation,
 it first dropped the ForeignKey constraint, then dropped the not-null
 constraint, and last re-created the ForeignKey constraint (3 statements).

 Re-creating ForeignKey constraints locks tables and can generate downtime.
 Since we cannot afford the downtime we used a
 [https://docs.djangoproject.com/en/2.1/ref/migration-operations/#runsql
 RunSQL] migration operation with `state_operations` as a **workaround**:

 {{{
 migrations.RunSQL(
"""--
-- Alter field trip on payment
--
ALTER TABLE "app_payment" ALTER COLUMN "trip_id" DROP NOT NULL;
""",
state_operations=[
migrations.AlterField(
model_name='payment',
name='trip',
field=models.ForeignKey(blank=True, null=True,
 on_delete=django.db.models.deletion.PROTECT,
related_name='payments',
 to='app.Trip'),
),
])
 }}}

 This way we only apply the SQL we want and Django won't complain about the
 migration state not matching the current model. :)

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

Re: [Django] #28373: TIME_ZONE value in DATABASES settings is not used for date lookup

[Django]

#28373: TIME_ZONE value in DATABASES settings is not used for date lookup
-+-
 Reporter:  Victor Talpaert  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  settings ORM lookup  | Triage Stage:  Accepted
  mysql timezone |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  messfish => (none)
 * status:  assigned => new


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

Re: [Django] #29975: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Django]

#29975: Password reset emails in combination with click tracking do not work 
with
Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave
-+-
 Reporter:  Mat Gadd |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  safari, privacy, | Triage Stage:  Accepted
  auth, password reset   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mat Gadd):

 Hi all,

 Thanks to the excellent work by Flávio Juvenal over on ticket #30250, we
 now have a workaround for this issue. It turns out to be a
 [https://bugs.webkit.org/show_bug.cgi?id=188165 bug in Safari] where it
 incorrectly handles cookies set with `SameSite=lax`, so setting
 `CSRF_COOKIE_SAMESITE` and `SESSION_COOKIE_SAMESITE` to `None` in your
 project settings will avoid this issue until Apple get around to deploying
 a fix for Safari.

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

[Django] #30267: GeoDjango does not create correct PostGIS index for 3D geometry fields

[Django]

#30267: GeoDjango does not create correct PostGIS index for 3D geometry fields
-+-
   Reporter:  Casper |  Owner:  nobody
  van der Wel|
   Type: | Status:  new
  Uncategorized  |
  Component:  GIS|Version:  1.11
   Severity:  Normal |   Keywords:  geodjango, postgis
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When I create a model with a 3D geometryfield, an index USING gist (geom
 gist_geometry_ops_nd) is created automatically by geodjango in my PostGIS
 database. However, the spatial lookups 'intersects' and 'bboverlaps' do
 not use this index, which I can confirm by explaining the queries. Below
 some code to reproduce this issue.

 I am not sure if this is a bug or if I am reporting a non-intended use
 case for 3D geometryfields. It appears to me as a pretty straightforward
 use case.

 The model:

 {{{
 from django.contrib.gis.db import models
 from django.db import connections
 from django.db.models.query import QuerySet

 class QuerySetExplain(QuerySet):
 def explain(self):
 cursor = connections[self.db].cursor()
 query, params = self.query.sql_with_params()
 cursor.execute('EXPLAIN %s' % query, params)
 return '\n'.join(r[0] for r in cursor.fetchall())

 class PolyModel(models.Model):
 objects = QuerySetExplain.as_manager()
 geometry = models.PolygonField(srid=28992, dim=3)
 }}}


 After creating and running migrations, I explain the following query:

 {{{
 >>> from django.contrib.gis.geos import Polygon
 >>> from my_app.models import PolyModel
 >>> bbox = Polygon.from_bbox((0, 0, 1, 1))
 >>> qs = PolyModel.objects.filter(geometry__intersects=bbox)
 >>> print(qs.explain())

 Seq Scan on my_app_polymodel  (cost=0.00..2964.00 rows=1 width=241)
   Filter: ((geometry &&
 
'010320E61001000500F03FF03FF03FF03F'::geometry)
 AND _st_intersects(geometry,
 
'010320E61001000500F03FF03FF03FF03F'::geometry))
 }}}

 This says that is used a sequential scan. **It did not use the index**
 The solution for me is creating the indices "USING gist (geometry)" with
 raw SQL.
 Looking at PostGIS manuals, it seems you have to use the operator &&& to
 actually use an ND index. I can confirm that in the sql shell.

 Versions: I am using django 1.11.20, PostGRES 9.3 with PostGIS 2.4. I also
 reproduced the issue in raw SQL using PostGRES 10.

 After glancing the django source code, it appears to me that it persists
 in master. But I did not run any tests.

 A quickfix would be always creating 2 indexes on 3D geometry fields. But
 that does seem a waste of resources. Using &&& instead of && as the
 'bboverlaps' lookup would probably a better fix, but I am not such a
 PostGIS expert that I can oversee the changes necessary in the django ORM.

 Thanks in advance for looking at this bug 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/052.c16c1bff6d7fe85fe524eb0f25638126%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30258: Failed to add CheckConstraint on IntegerRangeField

[Django]

#30258: Failed to add CheckConstraint on IntegerRangeField
-+-
 Reporter:  Tilman Koschnick |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 Tilman Koschnick):

 Hi, thanks for looking into this, and getting the fix into rc1!

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