Re: [Django] #31323: doc bugs: ptyhon -> python

[Django]

#31323: doc bugs: ptyhon -> python
---+--
 Reporter:  moqimoqidea|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  3.0
 Severity:  Normal |   Resolution:  duplicate
 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 felixxm):

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


Comment:

 Duplicate of #30782.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.756fb0ff1d1a84b18e74e9d653edec46%40djangoproject.com.

[Django] #31324: Filter JSONField using `=None`

[Django]

#31324: Filter JSONField using `=None`
---+
   Reporter:  Nikolay Tretyak  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Uncategorized|Version:  2.2
   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|
---+
 {{{
 from django.contrib.postgres.fields import JSONField
 from django.db import models

 class A(models.Model):
 field = JSONField(null=True)

 class Meta:
 app_label = 'T'

 print(A.objects.filter(field=None).query)  # SELECT "T_a"."id",
 "T_a"."field" FROM "T_a" WHERE "T_a"."field" = 'null'

 print(A.objects.filter(field__isnull=True).query)  # SELECT "T_a"."id",
 "T_a"."field" FROM "T_a" WHERE "T_a"."field" IS NULL
 }}}

 If I create a new object with {{{A.objects.create(field=None)}}}, it will
 be stored in the database as NULL. Therefore, I think it would be better
 to use {{{IS NULL}}} query in the first filter from the example. And it
 worked like this at least in 1.9

 Moreover, with the behavior that we have now I can't even do
 {{{A.objects.filter(field=existing_obj.field)}}} if {{{existing_obj.field
 is None}}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.d139de81cf517982e609e225384a588b%40djangoproject.com.

Re: [Django] #31324: Filter JSONField using `=None`

[Django]

#31324: Filter JSONField using `=None`
-+-
 Reporter:  Nikolay Tretyak  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nikolay Tretyak):

 * component:  Uncategorized => Database layer (models, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9cd7f013bd96724f7bdc4081e7264307%40djangoproject.com.

Re: [Django] #31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.

[Django]

#31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Adam (Chainz) Johnson):

 I've gone for a docs PR instead:
 https://github.com/django/django/pull/12511

 The reason I made this was when squashing migrations on a client project,
 it had some RunSQL operations in migrations that worked fine alone, but
 when the operatiosn were squashed together it broke the squashed
 migration's transactional state.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a708568d8e0b179a1a16944e2bc4fd78%40djangoproject.com.

Re: [Django] #31324: Filter JSONField using `=None`

[Django]

#31324: Filter JSONField using `=None`
-+-
 Reporter:  Nikolay Tretyak  |Owner:  Nikolay
 |  Tretyak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nikolay Tretyak):

 * owner:  nobody => Nikolay Tretyak
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2d408bfa8319d3bedefdcc40fc23%40djangoproject.com.

Re: [Django] #29308: Clarify how assertQuerysetEqual()'s transform parameter works

[Django]

#29308: Clarify how assertQuerysetEqual()'s transform parameter works
-+-
 Reporter:  Alexander Todorov|Owner:  shubham
 Type:   |  singh
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.0
 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 shubham singh ):

 * cc: shubham singh  (added)
 * owner:  nobody => shubham singh
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.92ce6442336e82026158bab24a345d00%40djangoproject.com.

Re: [Django] #31324: Filter JSONField using `=None`

[Django]

#31324: Filter JSONField using `=None`
-+-
 Reporter:  Nikolay Tretyak  |Owner:  Nikolay
 |  Tretyak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 Nikolay Tretyak):

 Test and possible fix: https://github.com/django/django/pull/12512/files

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.20f218ec6a444fffdf92521187849e9c%40djangoproject.com.

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sanskar Jaiswal):

 Replying to [comment:13 Simon Charette]:
 > Here's
 [https://github.com/django/django/compare/master...charettes:ticket-31255
 a branch pushing the idea above further].
 After going through this, I have built on top of this and further fixed
 the ManyToManyField removal test cases and added another test case for
 this ticket as well. How should I create the PR, given that I have built
 on top of your existing code.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a24eb4bb6752163a54d2e940ad106eaf%40djangoproject.com.

[Django] #31325: send a mail launch UnicodeError

[Django]

#31325: send a mail launch UnicodeError
-+-
   Reporter:  Reinier|  Owner:  nobody
  Hernandez Avila|
   Type:  Bug| Status:  new
  Component: |Version:  3.0
  Uncategorized  |
   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  |
-+-
 I published this question in stackoverflow
 [https://es.stackoverflow.com/questions/333444/unicodeerror-enviando-un-
 correo-en-django] when i try to send mail with send_mail method this
 return

 {{{
 UnicodeError at /accounts/email/
 encoding with 'idna' codec failed (UnicodeError: label empty or too long)
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.ae8145c941dd672f6bb24c7297a551d2%40djangoproject.com.

[Django] #31326: Deleting a concrete subclass table with no additional fields results results in invalid migration

[Django]

#31326: Deleting a concrete subclass table with no additional fields results
results in invalid migration
+
   Reporter:  Stephen Finucane  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |Version:  1.11
   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 |
+
 Take the following models

 {{{#!python
 class Parent(models.Model):
 name = models.CharField(max_length=255)

 class Child(Parent):
 pass
 }}}

 Attempting the delete `Child` will result in a migration like so:

 {{{#!python
 from django.db import migrations

 class Migration(migrations.Migration):
 dependencies = []

 operations = [
 migrations.RemoveField(
 model_name='child',
 name='parent_ptr',
 ),
 migrations.DeleteModel(
 name='Child',
 ),
 ]
 }}}

 Unfortunately this results in an error from PostgreSQL at least:

 {{{
 django.db.utils.OperationalError: (1090, "You can't delete all columns
 with ALTER TABLE; use DROP TABLE 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.7a369179df226a90813bb237e054eeda%40djangoproject.com.

Re: [Django] #31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.

[Django]

#31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Simon Charette):

 > The reason I made this was when squashing migrations on a client
 project, it had some RunSQL operations in migrations that worked fine
 alone, but when the operatiosn were squashed together it broke the
 squashed migration's transactional state.

 Interesting, were these migrations marked `atomic = False` initially? It
 looks like
 
[https://github.com/django/django/blob/2bd8df243ac6fc35e58c9fe90b20c9e42519a5ac/django/core/management/commands/squashmigrations.py#L165-L170
 the current code] completely ignores this flag. I guess the command could
 at least warn about it.

 Migration squashing is definitely an area that would benefit from a bit of
 love wrt to dependency resolving and could be a good GSOC project in the
 next years if we ever apply.

 From [https://docs.djangoproject.com/en/3.0/topics/migrations/#migration-
 squashing the docs themselves]

 > To manually resolve a CircularDependencyError, break out one of the
 ForeignKeys in the circular dependency loop into a separate migration, and
 move the dependency on the other app with it. If you’re unsure, see how
 makemigrations deals with the problem when asked to create brand new
 migrations from your models. **In a future release of Django,
 squashmigrations will be updated to attempt to resolve these errors
 itself.**

 It looks like non-atomic migrations pose a similar problem where they'd
 need to be considered an optimization barrier and require the creation of
 a standalone migration.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.90a3d8d7b2c6422a8ee990c3e718ac6e%40djangoproject.com.

Re: [Django] #11541: F() expressions don't allow assignment of Foreign Key values on instances

[Django]

#11541: F() expressions don't allow assignment of Foreign Key values on 
instances
-+-
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.1-beta
  (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 Simon Charette):

 > The only solution I could think of is to defer the test for F
 expressions until queryset evaluation.

 Abhijeet, the check can likely be deferred `if hasattr(value,
 resolve_expression)`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.be15708d00cc647eedf5799a2b535e9f%40djangoproject.com.

Re: [Django] #31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.

[Django]

#31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Adam (Chainz) Johnson):

 > Interesting, were these migrations marked atomic = False initially?

 No

 > It looks like non-atomic migrations pose a similar problem where they'd
 need to be considered an optimization barrier and require the creation of
 a standalone migration.

 Yes, that would be great

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7f61fbd9c83f60df405164fa34356df8%40djangoproject.com.

Re: [Django] #31324: Filter JSONField using `=None`

[Django]

#31324: Filter JSONField using `=None`
-+-
 Reporter:  Nikolay Tretyak  |Owner:  Nikolay
 |  Tretyak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (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 Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 I think that could be a 2.1 regression caused by fixing #25718
 (c979c0a2b8abca325a549961fd7a17bdc36bcb1f).

 It looks like it could qualify for a data loss bug because
 `Model.objects.filter(json_field=None).update(field=value)` would be a
 noop starting for `Model.json_field = None` instances.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9289e1a2cd5963557a0d5e12a5f2c131%40djangoproject.com.

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > After going through this, I have built on top of this and further fixed
 the ManyToManyField removal test cases and added another test case for
 this ticket as well

 Nice, I think `test_non_cyclical_models_removals` already covers this
 ticket's case though; no need to add another one at the auto-detector
 level IMO.

 > How should I create the PR, given that I have built on top of your
 existing code?

 Assuming you pushed your work to a branch that includes the above commit
 it should be the same process as opening any other PR. I'd leave the two
 commits separated so they can be reorganized by the mergers as they deem
 the most appropriate.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.22823ac55a300423f20b361733847438%40djangoproject.com.

Re: [Django] #31326: Deleting a concrete subclass table with no additional fields results results in invalid migration

[Django]

#31326: Deleting a concrete subclass table with no additional fields results
results in invalid migration
--+--
 Reporter:  Stephen Finucane  |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Uncategorized |  Version:  1.11
 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:

 You reported this issue on Django 1.11 but it cannot be reproduced anymore
 in Django 2.2+ (likely because of
 ad82900ad94ed4bbad050b9993373dafbe66b610).

 It can also be easily worked around by removing the `RemoveField`
 operation entirely.

 Closing this ticket as invalid because the patch won't be backported to
 1.11 (it only receives security backport 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6bd333b44a240eafc62837e67efecfe1%40djangoproject.com.

Re: [Django] #30224: Mysql Datetime value is string instead of datetime object

[Django]

#30224: Mysql Datetime value is string instead of datetime object
-+-
 Reporter:  Martin Kuhn  |Owner:  Rohit Jha
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  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 Rohit Jha):

 I am trying to recreate this issue, I have written a (test
 
case)[https://github.com/django/django/compare/master...rohitjha941:ticket_30224]
 which generates the following query:


 {{{
 SELECT "expressions_experiment"."id",
"expressions_experiment"."name",
"expressions_experiment"."assigned",
"expressions_experiment"."completed",
"expressions_experiment"."estimated_time",
"expressions_experiment"."start",
"expressions_experiment"."end",
Min(CASE
  WHEN "expressions_result"."experiment_id" = 1 THEN
  "expressions_result"."result_time"
  ELSE NULL
END) AS "min_expiry_date"
 FROM   "expressions_experiment"
LEFT OUTER JOIN "expressions_result"
 ON ( "expressions_experiment"."id" =
  "expressions_result"."experiment_id" )
 GROUP  BY "expressions_experiment"."id",
   "expressions_experiment"."name",
   "expressions_experiment"."assigned",
   "expressions_experiment"."completed",
   "expressions_experiment"."estimated_time",
   "expressions_experiment"."start",
   "expressions_experiment"."end"

 }}}

 and output is
 {{{
   [{'id': 1, 'name': 'Rohit', 'assigned': datetime.date(2020, 3, 1),
 'completed': datetime.date(2020, 3, 21), 'estimated_time':
 datetime.timedelta(days=20, seconds=36000), 'start':
 datetime.datetime(2020, 3, 1, 11, 23, 36, 34995), 'end':
 datetime.datetime(2020, 3, 21, 21, 23, 36, 34998), 'min_expiry_date':
 datetime.datetime(2020, 4, 20, 21, 23, 36, 35778)}]
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6f1f0595fa540738bb32a6f3fb6320ea%40djangoproject.com.

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sanskar Jaiswal):

 While working on my branch, I manually changed all the files to reflect
 the changes you made on your branch, and then made some further changes on
 my own. I was wondering if there is a way, that the megers recognize that
 the PR contains your work too, since if I simply create a PR, there would
 be no way of you getting any credit.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5a0e53e908f5bcc0658711fc9df3d441%40djangoproject.com.

[Django] #31327: Deprecate providing_args argument from Signal

[Django]

#31327: Deprecate providing_args argument from Signal
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Utilities |Version:  master
   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 |
+
 The argument is and always has been purely documentational. It provides no
 functionality or checking. Therefore, these values are stored in memory
 for no real use.

 Documentation can be handled just as easily by a code comment or real
 documentation articles.

 On a more practical level, I rarely signals, so I recently had to look up
 their interface. Seeing this `providing_args` argument required me to
 think about how to best use it, only to realize it actually goes unused.
 We can remove this cognitive distraction from the docs.

 It has caused other small confusion in the past: #19579.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.1a7085b3cceb96f483678a1faa52fcf7%40djangoproject.com.

Re: [Django] #31327: Deprecate providing_args argument from Signal

[Django]

#31327: Deprecate providing_args argument from Signal
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 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 Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12513

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7f71397cc51d93dd12a1e60d0fde2126%40djangoproject.com.

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I wouldn't worry too much about attribution, mergers can use the Git `Co-
 authored-by` feature to give attribution to multiple contributors.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2498314c7d419950440c1cd06ab9f5e7%40djangoproject.com.

Re: [Django] #29023: running tests in parallel doesn't show exception chain, even with tblib

[Django]

#29023: running tests in parallel doesn't show exception chain, even with tblib
-+-
 Reporter:  Chris Jerdonek   |Owner:  Ahmad
 Type:   |  Abdallah
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  parallel,exception,chain,traceback,pickling,tblib|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ahmad Abdallah):

 * owner:  nobody => Ahmad Abdallah
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.02ea284534a03be78897bb894c067143%40djangoproject.com.

Re: [Django] #31318: sqlmigrate doesn't allow inspecting migrations that have been squashed

[Django]

#31318: sqlmigrate doesn't allow inspecting migrations that have been squashed
-+-
 Reporter:  Adam (Chainz)|Owner:  David
  Johnson|  Wobrock
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * owner:  nobody => David Wobrock
 * status:  new => assigned


Comment:

 Hi! This seems quite relevant to me, as in the company I work for, we'll
 probably start using squashed migration soon-ish and we use sqlmigrate
 extensively.

 I'd like to tackle this change :)
 It does not seem too complicated to allowed inspecting the SQL of replaced
 migrations.
 I already wrote a small test that reproduces the behaviour described in
 the stacktrace.

 Technically, I guess I should be able to find an elegant way to detect the
 migration was replaced and find it in the MigrationLoader.
 Visually, should the command display that the inspected migration is
 replaced and by which squashed migration?

 Thanks!
 David

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.47609cacfadbacc8e44eb8970332270f%40djangoproject.com.

Re: [Django] #29329: Inconsistent datetime logging from runserver.

[Django]

#29329: Inconsistent datetime logging from runserver.
-+-
 Reporter:  Sjoerd Job Postmus   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  2.0
 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 Hasan Ramezani):

 * owner:  Srinivas Reddy Thatiparthy => Hasan Ramezani
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.dfac3eaa0f044d761ea5bbf68e49bf1b%40djangoproject.com.

Re: [Django] #31318: sqlmigrate doesn't allow inspecting migrations that have been squashed

[Django]

#31318: sqlmigrate doesn't allow inspecting migrations that have been squashed
-+-
 Reporter:  Adam (Chainz)|Owner:  David
  Johnson|  Wobrock
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 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 David Wobrock):

 * has_patch:  0 => 1


Comment:

 Patch: https://github.com/django/django/pull/12518

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1d971ee87dde76c10a0ed304aefda1d4%40djangoproject.com.

Re: [Django] #31150: Subquery annotations are omitted in group by query section if multiple annotation are declared

[Django]

#31150: Subquery annotations are omitted in group by query section if multiple
annotation are declared
-+-
 Reporter:  Johannes Hoppe   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 felixxm):

 * owner:  nobody => felixxm
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.749bca190c3a124d00aae81f282501a9%40djangoproject.com.

Re: [Django] #31325: Send a mail launch UnicodeError. (was: send a mail launch UnicodeError)

[Django]

#31325: Send a mail launch UnicodeError.
-+-
 Reporter:  Reinier Hernandez|Owner:  nobody
  Avila  |
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  3.0
 Severity:  Normal   |   Resolution:  needsinfo
 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 felixxm):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => Core (Mail)


Comment:

 It looks that domain part is invalid. Can you provide an email address
 that caused this exception?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.5d8ea68796917bb4f7dc79857779ae25%40djangoproject.com.

Re: [Django] #31318: sqlmigrate doesn't allow inspecting migrations that have been squashed

[Django]

#31318: sqlmigrate doesn't allow inspecting migrations that have been squashed
-+-
 Reporter:  Adam (Chainz)|Owner:  David
  Johnson|  Wobrock
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  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 felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.fd75ff881a830503283d8bcff63d3bcf%40djangoproject.com.

Re: [Django] #31316: handler500 called multiple times. (was: handler500 called multiple times)

[Django]

#31316: handler500 called multiple times.
---+--
 Reporter:  David Szotten  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  master
 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 felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Uncategorized => HTTP handling


Comment:

 `handler500` should return `HttpResponseServerError`, when it raises an
 exception then it's propagated to the next middleware and a custom handler
 is called again. This behavior is a side effect of an incorrect
 implementation of a custom `handler500`. It's called only once when
 returns `HttpResponseServerError` (as documented).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.8b73dc3b1b5d793dcd63ed03990ded64%40djangoproject.com.

Re: [Django] #26064: Move migration operation reduction logic to their respective class.

[Django]

#26064: Move migration operation reduction logic to their respective class.
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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
-+-

Comment (by GitHub ):

 In [changeset:"daaa894960e1b2bce8ee31b7c109be84f598a84e" daaa8949]:
 {{{
 #!CommitTicketReference repository=""
 revision="daaa894960e1b2bce8ee31b7c109be84f598a84e"
 Refs #26064 -- Avoided unnecessary list slicing in migration optimizer.

 The in_between list is only necessary if an optimization is possible.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.4bcfbd52b2388107f56d814dc0e5a627%40djangoproject.com.

Re: [Django] #31319: URL dispatcher does not handle multislashes. (was: urldispatcher does not handle multishlashes)

[Django]

#31319: URL dispatcher does not handle multislashes.
-+--
 Reporter:  Bjoern   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 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 felixxm):

 * status:  new => closed
 * resolution:   => wontfix
 * type:  Uncategorized => New feature
 * component:  Uncategorized => Core (URLs)


Comment:

 Thanks for this ticket, however I don't agree that URL dispatcher should
 merge slashes. This change would be backward incompatible and IMO it's
 something that lies within responsibility of a web server (like nginx).
 You can start a discussion on DevelopersMailingList if you don't agree.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d49b0b29c47d616a6861c6d6595b3a37%40djangoproject.com.