Re: [Django] #34417: AlterField migration on ForeignKey field re-creates foreign key constraints unnecessarily

[Django]

#34417: AlterField migration on ForeignKey field re-creates foreign key 
constraints
unnecessarily
--+
 Reporter:  Ömer Faruk Abacı  |Owner:  Bhuvnesh
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  4.1
 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 Bhuvnesh):

 * needs_better_patch:  1 => 0
 * owner:  Deniz Altun => Bhuvnesh

-- 
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/0107018f3093bdef-6238d1ef-ac53-4b5e-99db-70cae832db29-00%40eu-central-1.amazonses.com.

Re: [Django] #35417: RequestContext.new creates a context that cannot be flattened

[Django]

#35417: RequestContext.new creates a context that cannot be flattened
---+--
 Reporter:  Lily Foote |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  5.0
 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 Lily Foote):

 Investigating a bit more, this also applies to {{{Context}}} and
 {{{RenderContext}}}.
-- 
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/0107018f303b59b6-818a2b94-657d-4ef0-a907-e5c1f8a2d95a-00%40eu-central-1.amazonses.com.

Re: [Django] #35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used

[Django]

#35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used
--+
 Reporter:  bcail |Owner:  bcail
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:  dev
 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 bcail):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f302a4536-ab17c8de-7338-450a-991b-a5e90bf4f956-00%40eu-central-1.amazonses.com.

Re: [Django] #35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used

[Django]

#35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used
--+
 Reporter:  bcail |Owner:  bcail
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Sarah Boyce):

 * needs_better_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/0107018f2ff9b507-4ed3932c-4660-4012-9790-c13e471f9fe5-00%40eu-central-1.amazonses.com.

Re: [Django] #28358: LazyObject defines attribute that don't exist on wrapped object

[Django]

#28358: LazyObject defines attribute that don't exist on wrapped object
-+-
 Reporter:  Andrey Fedoseev  |Owner:  Theofilos
 |  Alexiou
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.11
 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 Lily Foote):

 The PyPy issue for the {{{ValueError: site must subclass AdminSite}}}
 exception has moved to https://github.com/pypy/pypy/issues/3750.

 I've just opened #35418 to track adding the workaround.
-- 
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/0107018f2fd0ff45-cc4b3c82-d88b-4b09-9c49-0b06304c037c-00%40eu-central-1.amazonses.com.

[Django] #35418: ValueError: site must subclass AdminSite

[Django]

#35418: ValueError: site must subclass AdminSite
-+
   Reporter:  Lily Foote |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  5.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In https://code.djangoproject.com/ticket/28358#comment:13 it was reported
 that running tests with Django, PyPy and Coverage would fail with a
 {{{ValueError: site must subclass AdminSite}}} exception. This can also be
 triggered on CPython when running Coverage in pure python mode. There are
 upstream tickets for [https://github.com/nedbat/coveragepy/issues/1382
 Coverage], [https://github.com/pypy/pypy/issues/3750 PyPy] and
 [https://github.com/python/cpython/issues/98148 CPython], but these are
 not seeing much progress. A small change to Django to workaround this was
 proposed in https://code.djangoproject.com/ticket/28358#comment:21, but
 this never landed: https://github.com/django/django/pull/16541

 I think we should land the workaround in Django so this isn't an issue
 even if upstream never finds a fix.
-- 
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/0107018f2fd02b2f-49689289-66c1-4bc8-9530-b260f89a0f8b-00%40eu-central-1.amazonses.com.

Re: [Django] #35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used

[Django]

#35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used
--+
 Reporter:  bcail |Owner:  bcail
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:  dev
 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 bcail):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f2f9060e6-95e0fe24-517c-4f02-a2b7-88aa78ed8fe1-00%40eu-central-1.amazonses.com.

Re: [Django] #35417: RequestContext.new creates a context that cannot be flattened

[Django]

#35417: RequestContext.new creates a context that cannot be flattened
---+--
 Reporter:  Lily Foote |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  5.0
 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
---+--
Description changed by Lily Foote:

Old description:

> In
> [https://github.com/django/django/blob/c187f5f9242b681abaa199173e02066997439425/django/template/library.py#L273
> InclusionNode.render] Django creates a {{{new_context}}} from two
> existing contexts ({{{context}}} and {{{_dict}}}) by calling
> {{{new_context = context.new(_dict)}}}. These can both be instances of
> {{{RequestContext}}} leading to {{{new_context}}} also being a
> {{{RequestContext}}} (I have not tried with any other context types).
> However, calling {{{new_context.flatten()}}} raises a {{{ValueError}}}:
>
> {{{
> ValueError: dictionary update sequence element #0 has length 1; 2 is
> required
> }}}
>
> I can reproduce this in a small test:
>
> {{{
> from django.template.context import RequestContext
> from django.test import RequestFactory, TestCase
>

> class RequestContextTestCase(TestCase):
> def test_flatten_request_context_new(self):
> factory = RequestFactory()
>
> request = factory.get("/foo/")
> context = RequestContext(request)
> context_2 = RequestContext(request)
> context_3 = context.new(context_2)
>
> self.assertEqual(
> context_3.flatten(), {"False": False, "None": None, "True":
> True}
> )
> }}}
>
> I discovered this when running Kolo on a Django admin view
> (http://127.0.0.1:8000/admin/auth/user/). Kolo calls
> {{{context.flatten()}}} internally when introspecting a template during
> rendering, which leads to this exception:
>
> {{{
> Traceback (most recent call last):
>   File
> "/home/lily/work/kloppindustries/kolo/python/src/kolo/profiler.py", line
> 170, in __call__
> frame_data = processor.process(
>  ^^
>   File "/home/lily/work/kloppindustries/kolo/python/src/kolo/plugins.py",
> line 107, in process
> data.update(self.process_extra(frame, event, arg, self.context))
> ^^^
>   File
> "/home/lily/work/kloppindustries/kolo/python/src/kolo/filters/django.py",
> line 89, in process_django_template
> template_context = template_context.flatten()
>^^
>   File "/home/lily/.local/share/lilyenv/virtualenvs/kolo-
> sandbox/3.12/lib/python3.12/site-packages/django/template/context.py",
> line 120, in flatten
> flat.update(d)
> ValueError: dictionary update sequence element #0 has length 3; 2 is
> required
> }}}

New description:

 In
 
[https://github.com/django/django/blob/c187f5f9242b681abaa199173e02066997439425/django/template/library.py#L273
 InclusionNode.render] Django creates a {{{new_context}}} from two existing
 contexts ({{{context}}} and {{{_dict}}}) by calling {{{new_context =
 context.new(_dict)}}}. These can both be instances of {{{RequestContext}}}
 leading to {{{new_context}}} also being a {{{RequestContext}}} (I have not
 tried with any other context types). However, calling
 {{{new_context.flatten()}}} raises a {{{ValueError}}}:

 {{{
 ValueError: dictionary update sequence element #0 has length 1; 2 is
 required
 }}}

 I can reproduce this in a small test:

 {{{
 from django.template.context import RequestContext
 from django.test import RequestFactory, TestCase


 class RequestContextTestCase(TestCase):
 def test_flatten_request_context_new(self):
 factory = RequestFactory()

 request = factory.get("/foo/")
 context = RequestContext(request)
 context_2 = RequestContext(request)
 context_3 = context.new(context_2)

 self.assertEqual(
 context_3.flatten(), {"False": False, "None": None, "True":
 True}
 )
 }}}

 I discovered this when running Kolo on a Django admin view
 (http://127.0.0.1:8000/admin/auth/user/). Kolo calls
 {{{context.flatten()}}} internally when introspecting a template during
 rendering, which leads to this exception:

 {{{
 Traceback (most recent call last):
   File "/home/lily/work/kloppindustries/kolo/python/src/kolo/profiler.py",
 line 170, in __call__
 frame_data = processor.process(
  ^^
   File "/home/lily/work/kloppindustries/kolo/python/src/kolo/plugins.py",
 line 107, in process
 data.update(self.process_extra(frame, event, 

Re: [Django] #35415: Adding content_type to StreamingHttpResponse on Linux causes memory error after streaming around 1GB-2GB of data.

[Django]

#35415: Adding content_type to StreamingHttpResponse on Linux causes memory 
error
after streaming around 1GB-2GB of data.
---+--
 Reporter:  LouisB12345|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  5.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 Sarah Boyce):

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

Comment:

 Hi LouisB12345, this looks a little unusual to me as you have a sync view
 calling an async function.
 Maybe because of the context switching between sync and async it's waiting
 for the data to accumulate before sending? What server are you running
 here?

 I recommend you post on [https://forum.djangoproject.com/c/users/async-
 channels/23 the forum], verify that `StreamingHttpResponse` is being used
 as expected, and Django is at fault here.
-- 
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/0107018f2f8d1377-7ab3a20d-b2e9-4f09-81e2-c8ecc2bce401-00%40eu-central-1.amazonses.com.

[Django] #35417: RequestContext.new creates a context that cannot be flattened

[Django]

#35417: RequestContext.new creates a context that cannot be flattened
-+
   Reporter:  Lily Foote |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  5.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In
 
[https://github.com/django/django/blob/c187f5f9242b681abaa199173e02066997439425/django/template/library.py#L273
 InclusionNode.render] Django creates a {{{new_context}}} from two existing
 contexts ({{{context}}} and {{{_dict}}}) by calling {{{new_context =
 context.new(_dict)}}}. These can both be instances of {{{RequestContext}}}
 leading to {{{new_context}}} also being a {{{RequestContext}}} (I have not
 tried with any other context types). However, calling
 {{{new_context.flatten()}}} raises a {{{ValueError}}}:

 {{{
 ValueError: dictionary update sequence element #0 has length 1; 2 is
 required
 }}}

 I can reproduce this in a small test:

 {{{
 from django.template.context import RequestContext
 from django.test import RequestFactory, TestCase


 class RequestContextTestCase(TestCase):
 def test_flatten_request_context_new(self):
 factory = RequestFactory()

 request = factory.get("/foo/")
 context = RequestContext(request)
 context_2 = RequestContext(request)
 context_3 = context.new(context_2)

 self.assertEqual(
 context_3.flatten(), {"False": False, "None": None, "True":
 True}
 )
 }}}

 I discovered this when running Kolo on a Django admin view
 (http://127.0.0.1:8000/admin/auth/user/). Kolo calls
 {{{context.flatten()}}} internally when introspecting a template during
 rendering, which leads to this exception:

 {{{
 Traceback (most recent call last):
   File "/home/lily/work/kloppindustries/kolo/python/src/kolo/profiler.py",
 line 170, in __call__
 frame_data = processor.process(
  ^^
   File "/home/lily/work/kloppindustries/kolo/python/src/kolo/plugins.py",
 line 107, in process
 data.update(self.process_extra(frame, event, arg, self.context))
 ^^^
   File
 "/home/lily/work/kloppindustries/kolo/python/src/kolo/filters/django.py",
 line 89, in process_django_template
 template_context = template_context.flatten()
^^
   File "/home/lily/.local/share/lilyenv/virtualenvs/kolo-
 sandbox/3.12/lib/python3.12/site-packages/django/template/context.py",
 line 120, in flatten
 flat.update(d)
 ValueError: dictionary update sequence element #0 has length 3; 2 is
 required
 }}}
-- 
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/0107018f2f8b2174-0d33b315-bbe2-4ea2-a2eb-40f7e4c1be6f-00%40eu-central-1.amazonses.com.

Re: [Django] #22997: Migration fails when removing explicit primary key (was: Migration fails when removing explicit primary key (Postgres))

[Django]

#22997: Migration fails when removing explicit primary key
-+
 Reporter:  a.lloyd.flanagan@…   |Owner:  bcail
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate primary_key  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Sarah Boyce):

 * needs_better_patch:  0 => 1
 * summary:  Migration fails when removing explicit primary key (Postgres)
 => Migration fails when removing explicit primary key

Comment:

 #35416 is a duplicate.
 Marking "Patch needs improvement" as the case, as described in #35416,
 needs to be handled.
-- 
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/0107018f2f7bb104-db343e6c-3793-4e3b-85ce-e0adc4f445e8-00%40eu-central-1.amazonses.com.

Re: [Django] #35416: Removing a primary_key field causes a migration crash

[Django]

#35416: Removing a primary_key field causes a migration crash
-+--
 Reporter:  Sarah Boyce  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  dev
 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 Sarah Boyce):

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

Comment:

 Thank you for verifying - duplicate of #22997.
-- 
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/0107018f2f7a0870-89c78202-8c71-4a44-9da3-ac459a8e155a-00%40eu-central-1.amazonses.com.

Re: [Django] #35416: Removing a primary_key field causes a migration crash

[Django]

#35416: Removing a primary_key field causes a migration crash
-+--
 Reporter:  Sarah Boyce  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  dev
 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 Simon Charette):

 I would qualify this as a duplicate of #22997 as changing a model from

 {{{#!python
 class MySimpleModel(models.Model):
 some_pk = models.IntegerField(primary_key=True)
 }}}

 to

 {{{#!python
 class MySimpleModel(models.Model):
 pass
 }}}

 Is exactly ''removing an explicit primary key''.

 The ticket also describes the questioner asking about providing a default
 value.

 I think that your first instinct was right, this is the same issue which
 is not specific to Postgres.
-- 
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/0107018f2f6377e2-1c2ac120-7426-4aa2-b1ab-dd39d18722e9-00%40eu-central-1.amazonses.com.

Re: [Django] #35416: Removing a primary_key field causes a migration crash

[Django]

#35416: Removing a primary_key field causes a migration crash
-+--
 Reporter:  Sarah Boyce  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  dev
 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 Sarah Boyce):

 * type:  Uncategorized => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f2ee82758-5cd68772-64df-4114-9929-901cd431db59-00%40eu-central-1.amazonses.com.

[Django] #35416: Removing a primary_key field causes a migration crash

[Django]

#35416: Removing a primary_key field causes a migration crash
-+
   Reporter:  Sarah Boyce|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Migrations |Version:  dev
   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  |
-+
 [I am using SQLite]

 Create a model with a primary_key field and makemigrations and migrate
 {{{#!python
 from django.db import models


 class MySimpleModel(models.Model):
 some_pk = models.IntegerField(primary_key=True)
 }}}
 Then remove the field and makemigrations
 {{{#!python
 class MySimpleModel(models.Model):
 pass
 }}}
 This prompts you to supply a default because

 {{{
 It is impossible to add a non-nullable field 'id' to mysimplemodel without
 specifying a default.
 }}}
 If you supply a default, you get a migration like this:

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


 class Migration(migrations.Migration):

 dependencies = [
 ('app3', '0001_initial'),
 ]

 operations = [
 migrations.RemoveField(
 model_name='mysimplemodel',
 name='some_pk',
 ),
 migrations.AddField(
 model_name='mysimplemodel',
 name='id',
 field=models.BigAutoField(auto_created=True, default=1,
 primary_key=True, serialize=False, verbose_name='ID'),
 preserve_default=False,
 ),
 ]
 }}}
 This crashes when you migrate with:
 {{{
 django.db.utils.OperationalError: near ")": syntax error
 }}}

 But if you remove the provided default from the migration and switch the
 order so that the field is added before the previous primary_key field is
 removed, the migration can be applied.


 This is very similar to #22997 and certainly related (they didn't remove
 the field but instead altered the field to no longer be a primary_key in
 that ticket).
 I am not sure whether to class this as a duplicate and require a fix as
 part of #22997 - happy to hear opinions here.
-- 
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/0107018f2ee72eba-ad63b6e2-a68d-4e45-a6b0-822d487acf71-00%40eu-central-1.amazonses.com.

Re: [Django] #22997: Migration fails when removing explicit primary key (Postgres) (was: Migration fails when removing explicit primary key)

[Django]

#22997: Migration fails when removing explicit primary key (Postgres)
-+
 Reporter:  a.lloyd.flanagan@…   |Owner:  bcail
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate primary_key  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Sarah Boyce):

 * summary:  Migration fails when removing explicit primary key => Migration
 fails when removing explicit primary key (Postgres)

Comment:

 (Ah perhaps the fix as described is only related to Postgres? Can confirm
 the same migrations and prompting happen on other databases).
-- 
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/0107018f2e872bc1-ad00c365-7ac9-4447-b2ec-8868bcd25d8c-00%40eu-central-1.amazonses.com.

Re: [Django] #35414: Issue with AsyncClient ignoring default headers compared to synchronous Client

[Django]

#35414: Issue with AsyncClient ignoring default headers compared to synchronous
Client
-+-
 Reporter:  설원준(Wonjoon   |Owner:  nobody
  Seol)/Dispatch squad   |
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  AsyncClient, | Triage Stage:
  ASGIRequest|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by 설원준(Wonjoon Seol)/Dispatch squad):

 Hi Sarah, the pytest fixture is only there to reduce boilerplates.
 Here is your requested test case without dependencies.

 **polls/views.py**

 {{{
 from django.http import JsonResponse
 def index(request):
 data = {"message": "This is an example API response"}
 return JsonResponse(data)
 }}}


 **middleware.py (Not required, can just print self.META inside
 ASGIRequest.**
 {{{
 class JWTMiddleware:
 def __init__(self, get_response):
 self.get_response = get_response

 def __call__(self, request):
 if 'HTTP_AUTHORIZATION' not in request.META:
 return JsonResponse({'error': 'Authorization header is
 missing'}, status=401)
 return self.get_response(request)
 }}}

 **polls/tests.py**
 {{{

 from http import HTTPStatus

 from django.test import TestCase, AsyncClient
 from django.urls import reverse


 class EXAMPLE_TESTS(TestCase):
 async def test_should_return_ok( # Fails
 self,
 ) -> None:
 async_client = AsyncClient(HTTP_AUTHORIZATION=f"Bearer
 I_AM_JWT_TOKEN") # AUTHORIZATION, HTTP_AUTHORIZATION both fails due to the
 reason in the original post.

 response = await async_client.get(
 reverse("index"),
 )

 self.assertEqual(response.status_code, HTTPStatus.OK)

 async def test_should_return_ok2( # Passes
 self,
 ) -> None:
 async_client = AsyncClient()

 response = await async_client.get(
 reverse("index"),
 AUTHORIZATION=f"Bearer I_AM_JWT_TOKEN"
 )

 self.assertEqual(response.status_code, HTTPStatus.OK)
 }}}



 {{{
 **printing META: (Customer header missing)**
 {'REQUEST_METHOD': 'GET', 'QUERY_STRING': '', 'SCRIPT_NAME': '',
 'PATH_INFO': '/polls/', 'wsgi.multithread': True, 'wsgi.multiprocess':
 True, 'REMOTE_ADDR': '127.0.0.1', 'REMOTE_HOST': '127.0.0.1',
 'REMOTE_PORT': 0, 'SERVER_NAME': '127.0.0.1', 'SERVER_PORT': '80',
 'HTTP_HOST': 'testserver', 'HTTP_COOKIE': ''}

 F
 ==
 FAIL: test_should_return_ok
 (polls.tests.EXAMPLE_TESTS.test_should_return_ok)
 --
 Traceback (most recent call last):
 ...
   File "/Users/.../workspace/django-mvp/mysite/polls/tests.py", line 17,
 in test_should_return_ok
 self.assertEqual(response.status_code, HTTPStatus.OK)
 AssertionError: 401 != 

 Ran 2 tests in 0.012s

 FAILED (failures=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/0107018f2e81f32f-9edb90e9-b9e4-467d-901c-afe3a3347e15-00%40eu-central-1.amazonses.com.

Re: [Django] #22997: Migration fails when removing explicit primary key (was: Migration fails when removing explicit primary key (Postgres))

[Django]

#22997: Migration fails when removing explicit primary key
-+
 Reporter:  a.lloyd.flanagan@…   |Owner:  bcail
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate primary_key  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Sarah Boyce):

 * summary:  Migration fails when removing explicit primary key (Postgres)
 => Migration fails when removing explicit primary key

Comment:

 (I can replicate also on SQLite so removing Postgres reference as it does
 not only relate to Postgres)
-- 
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/0107018f2e80fbdf-5ee58931-04f8-4b54-ba4a-3e8e149cefba-00%40eu-central-1.amazonses.com.

Re: [Django] #35415: Adding content_type to StreamingHttpResponse on Linux causes memory error after streaming around 1GB-2GB of data.

[Django]

#35415: Adding content_type to StreamingHttpResponse on Linux causes memory 
error
after streaming around 1GB-2GB of data.
---+--
 Reporter:  LouisB12345|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  5.0
 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 LouisB12345):

 I have some images that i want to attach, but for some reason i can upload
 them? Because it is 80+% chance to be spam according to SpamBayes.
-- 
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/0107018f2e7bc963-a4e79dc9-ff9a-44f8-bcb0-ce343992b645-00%40eu-central-1.amazonses.com.

[Django] #35415: Adding content_type to StreamingHttpResponse on Linux causes memory error after streaming around 1GB-2GB of data.

[Django]

#35415: Adding content_type to StreamingHttpResponse on Linux causes memory 
error
after streaming around 1GB-2GB of data.
-+
   Reporter:  LouisB12345|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |Version:  5.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 This bug took a few days to work out and was extremely annoying.
 I'm running Django under ASGI and im using was trying to use to stream a
 on-the-fly zip-file using the StreamingHttpResponse, note: i dont know if
 this occurs under WSGI.
 I'm developing on a Windows operating system and after I deemed the code
 to be functional i tried it on the Linux vm i have set up.
 I noticed that the download would fail almost everytime. The cause was
 that the memory usage kept increasing after some time, usually after
 around 1-2GB was streamed. So after eliminating multiple factors I came to
 the conclusion that when i add content_type= withing the
 StreamingHttpResponse this bug occurs.

 You can replicate the bug on Linux with the code below, if you remove the
 content_type it works as expected but with it the bug occurs.
 {{{
 from os.path import basename
 import logging
 import aiofiles
 from django.contrib.auth.mixins import LoginRequiredMixin
 from django.http import StreamingHttpResponse
 from django.views import View
 from guppy import hpy

 H = hpy()

 LOGGER = logging.getLogger(__name__)


 class DownloadSelectedFiles(LoginRequiredMixin, View):
 def get(self, request) -> StreamingHttpResponse:
 file_name = "f.txt"
 response = StreamingHttpResponse(file_data(file_name),
 content_type="application/octet-stream")
 response["Content-Disposition"] = f'attachment;
 filename="{basename(file_name)}"'
 return response


 async def file_data(file_path):
 async with aiofiles.open(file_path, "rb") as f:
 LOGGER.info(f"Current threads are {threading.active_count()}
 opening file {file_path}\n{H.heap()}")
 teller = 0
 while chunk := await f.read(65536):
 teller += 1
 await asyncio.sleep(0)
 if teller % 1000 == 0:
 LOGGER.info(f"Current threads are
 {threading.active_count()} yielding chunk nr.{teller}\n{H.heap()}")
 yield chunk
 }}}

 I have some images of the output of the Logs to show the difference.
-- 
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/0107018f2e706881-9c5cd35a-9273-455c-9ef4-9129448c3f50-00%40eu-central-1.amazonses.com.

Re: [Django] #32819: Fields’ help text and errors should be associated with input

[Django]

#32819: Fields’ help text and errors should be associated with input
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:  Accepted
  forms  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Comment (by Sarah Boyce <42296566+sarahboyce@…>):

 In [changeset:"c187f5f9242b681abaa199173e02066997439425" c187f5f9]:
 {{{#!CommitTicketReference repository=""
 revision="c187f5f9242b681abaa199173e02066997439425"
 Refs #32819 -- Avoided adding 'aria-describedby' to hidden inputs.

 Hidden elements are not visible for both accessibility tools and browsers
 presentation layer. This change therefore only reduces the size of the
 generated HTML.
 }}}
-- 
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/0107018f2e45aa1e-932f9abb-867b-45d5-b59f-d92af8b8cace-00%40eu-central-1.amazonses.com.

Re: [Django] #35378: Incorrect folding of long address headers with special characters when using 7bit Content-Transfer-Encoding in EmailMessage

[Django]

#35378: Incorrect folding of long address headers with special characters when
using 7bit Content-Transfer-Encoding in EmailMessage
-+-
 Reporter:  andres   |Owner:  Lufafa Joshua
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * needs_better_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/0107018f2e42adc6-a3a9a4ce-4cf8-4ec1-8b99-f25e5d238c1d-00%40eu-central-1.amazonses.com.

Re: [Django] #35414: Issue with AsyncClient ignoring default headers compared to synchronous Client

[Django]

#35414: Issue with AsyncClient ignoring default headers compared to synchronous
Client
-+-
 Reporter:  설원준(Wonjoon   |Owner:  nobody
  Seol)/Dispatch squad   |
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  AsyncClient, | Triage Stage:
  ASGIRequest|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

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

Comment:

 Hi 설원준(Wonjoon Seol)/Dispatch squad 
 I can see you are using pytest, which is an external dependency, there's a
 good chance you are using others.
 I need to be able to replicate an issue using **only** Django and
 currently it's quite hard to understand what's going on.

 I think Trac is not the right place to discuss this at this point, perhaps
 you want to ask for support on [https://forum.djangoproject.com/c/users/6
 the Django forum] or perhaps you want to raise this with a different
 dependency (perhaps [https://github.com/pytest-dev/pytest-django/issues
 pytest-django] is more appropriate?).
 If you can write a test case for Django that shows the issue without using
 pytest, then I think we can reopen the ticket 
-- 
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/0107018f2deabec6-03fb203e-8254-40b3-b3d6-37c8d779454d-00%40eu-central-1.amazonses.com.

Re: [Django] #32819: Fields’ help text and errors should be associated with input

[Django]

#32819: Fields’ help text and errors should be associated with input
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:  Accepted
  forms  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by David Smith):

 * needs_better_patch:  1 => 0

Comment:

 [https://github.com/django/django/pull/18113 PR] to avoid adding `aria-
 describedby` to `hidden` inputs.
-- 
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/0107018f2db125a9-3fab2fbd-c0f8-4f55-a2c2-59d854f255df-00%40eu-central-1.amazonses.com.