Re: [Django] #34930: Parallel tests fail on Python 3.11+ and MacOS.

2023-10-26 Thread Django 
#34930: Parallel tests fail on Python 3.11+ and MacOS.
-+-
 Reporter:  Matt Hegarty |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  pickle   | Triage Stage:
  _contextvars.Context _contextvars  |  Unreviewed
  Context|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

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


Comment:

 I can confirm I also get the reported error with the given reproducer,
 running on a Manjaro system (amd64):

 {{{
 Traceback (most recent call last):
   File "/home/nessita/fellowship/django/tests/runtests.py", line 783, in
 
 failures = django_tests(
^
   File "/home/nessita/fellowship/django/tests/runtests.py", line 421, in
 django_tests
 failures = test_runner.run_tests(test_labels)
^^
   File "/home/nessita/fellowship/django/django/test/runner.py", line 1068,
 in run_tests
 result = self.run_suite(suite)
  ^
   File "/home/nessita/fellowship/django/django/test/runner.py", line 995,
 in run_suite
 return runner.run(suite)
^
   File "/usr/lib/python3.11/unittest/runner.py", line 217, in run
 test(result)
   File "/usr/lib/python3.11/unittest/suite.py", line 84, in __call__
 return self.run(*args, **kwds)
^^^
   File "/home/nessita/fellowship/django/django/test/runner.py", line 541,
 in run
 subsuite_index, events = test_results.next(timeout=0.1)
  ^^
   File "/usr/lib/python3.11/multiprocessing/pool.py", line 873, in next
 raise value
   File "/usr/lib/python3.11/multiprocessing/pool.py", line 540, in
 _handle_tasks
 put(task)
   File "/usr/lib/python3.11/multiprocessing/connection.py", line 205, in
 send
 self._send_bytes(_ForkingPickler.dumps(obj))
  ^^
   File "/usr/lib/python3.11/multiprocessing/reduction.py", line 51, in
 dumps
 cls(buf, protocol).dump(obj)
 TypeError: cannot pickle '_contextvars.Context' object
 Exception ignored in: 
 Traceback (most recent call last):
   File "/usr/lib/python3.11/multiprocessing/pool.py", line 268, in __del__
 ResourceWarning: unclosed running multiprocessing pool
 
 }}}

 What I don't have clarity is whether this ever worked, I have bisected up
 to the adding of ASGI support (commit
 `a415ce70bef6d91036b00dd2c8544aed7aeeaaed`) and the given tests are still
 failing. I have also checked out `stable/4.0.x` and the tests are still
 not working.

 Matt, can you please explain how Django is at fault here? It seems that
 `IsolatedAsyncioTestCase` hasn't been (ever?) supported?

-- 
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/0107018b6edced59-e5469bc0-4708-4946-9e21-eb503ad9534e-00%40eu-central-1.amazonses.com.

Re: [Django] #15578: loaddata and processing order of fixtures

2023-10-26 Thread Django 
#15578: loaddata and processing order of fixtures
-+-
 Reporter:  Luc Saffre   |Owner:  Leo
 Type:   |  Suarez
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natalia <124304+nessita@…>):

 In [changeset:"43a36460703dfcf90dd309f0ff7306589b371e61" 43a3646]:
 {{{
 #!CommitTicketReference repository=""
 revision="43a36460703dfcf90dd309f0ff7306589b371e61"
 [4.2.x] Fixed #15578 -- Stated the processing order of fixtures in the
 fixtures docs.

 Also, added details about loading multiple fixtures and unified line
 wrapping
 at 79 cols.

 Co-Authored-By: Aniketh Babu 
 Co-Authored-by: Mariusz Felisiak 
 Co-Authored-By: Natalia Bidart <124304+ness...@users.noreply.github.com>

 Backport of 334dc073b1d9c89692aa5b11d362fb1cceae7a4a from main
 }}}

-- 
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/0107018b6e9ed238-047e4b77-d2ef-4103-9eee-e905c83d8708-00%40eu-central-1.amazonses.com.

Re: [Django] #15578: loaddata and processing order of fixtures

2023-10-26 Thread Django 
#15578: loaddata and processing order of fixtures
-+-
 Reporter:  Luc Saffre   |Owner:  Leo
 Type:   |  Suarez
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natalia <124304+nessita@…>):

 In [changeset:"89e539488a85fc08298b76215fce4b9b4cb4104b" 89e5394]:
 {{{
 #!CommitTicketReference repository=""
 revision="89e539488a85fc08298b76215fce4b9b4cb4104b"
 [5.0.x] Fixed #15578 -- Stated the processing order of fixtures in the
 fixtures docs.

 Also, added details about loading multiple fixtures and unified line
 wrapping
 at 79 cols.

 Co-Authored-By: Aniketh Babu 
 Co-Authored-by: Mariusz Felisiak 
 Co-Authored-By: Natalia Bidart <124304+ness...@users.noreply.github.com>

 Backport of 334dc073b1d9c89692aa5b11d362fb1cceae7a4a from main
 }}}

-- 
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/0107018b6e9df538-91c8f695-681a-4595-a01a-343876f98786-00%40eu-central-1.amazonses.com.

Re: [Django] #15578: loaddata and processing order of fixtures

2023-10-26 Thread Django 
#15578: loaddata and processing order of fixtures
-+-
 Reporter:  Luc Saffre   |Owner:  Leo
 Type:   |  Suarez
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 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 Natalia <124304+nessita@…>):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"334dc073b1d9c89692aa5b11d362fb1cceae7a4a" 334dc07]:
 {{{
 #!CommitTicketReference repository=""
 revision="334dc073b1d9c89692aa5b11d362fb1cceae7a4a"
 Fixed #15578 -- Stated the processing order of fixtures in the fixtures
 docs.

 Also, added details about loading multiple fixtures and unified line
 wrapping
 at 79 cols.

 Co-Authored-By: Aniketh Babu 
 Co-Authored-by: Mariusz Felisiak 
 Co-Authored-By: Natalia Bidart <124304+ness...@users.noreply.github.com>
 }}}

-- 
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/0107018b6e9c6449-dde70855-2333-441a-8204-2a9b7f1dd7c9-00%40eu-central-1.amazonses.com.

Re: [Django] #34925: refresh_from_db() will not iterate through all of the fields listed in the 'fields' parameter.

2023-10-26 Thread Django 
#34925: refresh_from_db() will not iterate through all of the fields listed in 
the
'fields' parameter.
-+-
 Reporter:  Andrew Cordery   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by David Sanders):

 @trontelj sure   Submit a PR and assign yourself. If you need assistance
 please head over to Discord to seek help from a community member.

-- 
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/0107018b6e736fde-ae957c0e-5392-4c3e-9609-f08b16aae679-00%40eu-central-1.amazonses.com.

Re: [Django] #34930: Parallel tests fail on Python 3.11+ and MacOS.

2023-10-26 Thread Django 
#34930: Parallel tests fail on Python 3.11+ and MacOS.
-+-
 Reporter:  Matt Hegarty |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  pickle   | Triage Stage:
  _contextvars.Context _contextvars  |  Unreviewed
  Context|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matt Hegarty):

 * Attachment "django_4_1_0_issue.txt" added.

 stack trace from 4.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/0107018b6de42804-1d413c00-2027-4592-96cd-3aaae9d517c7-00%40eu-central-1.amazonses.com.

Re: [Django] #34930: Parallel tests fail on Python 3.11+ and MacOS.

2023-10-26 Thread Django 
#34930: Parallel tests fail on Python 3.11+ and MacOS.
-+-
 Reporter:  Matt Hegarty |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  pickle   | Triage Stage:
  _contextvars.Context _contextvars  |  Unreviewed
  Context|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matt Hegarty):

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


-- 
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/0107018b6de32681-9c4bf3d4-e0ae-4eee-8318-5741aa026e85-00%40eu-central-1.amazonses.com.

Re: [Django] #34930: Parallel tests fail on Python 3.11+ and MacOS.

2023-10-26 Thread Django 
#34930: Parallel tests fail on Python 3.11+ and MacOS.
-+-
 Reporter:  Matt Hegarty |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  pickle   | Triage Stage:
  _contextvars.Context _contextvars  |  Unreviewed
  Context|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matt Hegarty):

 - Reproducible on Ubuntu and MacOS
 - using python 3.11 or 3.12 (3.10 is ok)
 - using Django 4.1 or higher (4.0.10 is ok)
 - Needs to have 2 or more test classes
 - 1 class has to subclass IsolatedAsyncioTestCase

 This will show the issue:

 {{{
 git clone g...@github.com:matthewhegarty/tutorial.git
 cd tutorial
 mkvirtualenv -p `which python3.11` -r requirements.txt tutorial-311

 # fails
 ./manage.py test --parallel

 # ok
 ./manage.py test
 }}}

 Some other testing

 - Django 4.0.10 [OK]
 - Django 4.1 [FAIL] (but with different error)
 - Django 4.1.1 [FAIL] (error from
 https://code.djangoproject.com/ticket/34010)
 - Django 4.1.2 [FAIL] (first instance of this error)
 - Django 4.1.8 [FAIL]

-- 
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/0107018b6de2c049-8a0d32e6-7813-4879-a2a4-0d2ca77ccac9-00%40eu-central-1.amazonses.com.

Re: [Django] #34931: QuerySet .count() crashes when queryset contains FilteredRelation referencing annotation in condition

2023-10-26 Thread Django 
#34931: QuerySet .count() crashes when queryset contains FilteredRelation
referencing annotation in condition
-+-
 Reporter:  Ben Nace |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 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 Mariusz Felisiak):

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


Comment:

 Duplicate of #33766, fixed in d660cee5bc68b597503c2a16f3d9928d52f93fb4
 (Django 5.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/0107018b6d4f166e-da769ac7-28a6-4adc-8957-0569e32f15c0-00%40eu-central-1.amazonses.com.

Re: [Django] #34930: Parallel tests fail on Python 3.11+ and MacOS. (was: Parallel tests fail in python 3.11 and 3.12)

2023-10-26 Thread Django 
#34930: Parallel tests fail on Python 3.11+ and MacOS.
-+-
 Reporter:  Matt Hegarty |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  pickle   | Triage Stage:
  _contextvars.Context _contextvars  |  Unreviewed
  Context|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this report. However, as far as I'm aware, Python versions
 shipped with `homebrew` have various issues and it's not recommended to
 use. I don't think you've explained the issue in enough detail to confirm
 a bug in Django. Folks are running our test suite on MacOS without any
 issues. This also has nothing to do with #34010. Moreover, Django 4.2
 doesn't officially support Python 3.12 yet.

 Please reopen the ticket if you can debug your issue and provide details
 about why and where Django is at fault. You can try to use one of
 [TicketClosingReasons/UseSupportChannels support channels] where will help
 you debug your issue.

-- 
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/0107018b6d4689ca-5864db82-2f83-4784-b129-26afb20835ec-00%40eu-central-1.amazonses.com.

[Django] #34931: QuerySet .count() crashes when queryset contains FilteredRelation referencing annotation in condition

2023-10-26 Thread Django 
#34931: QuerySet .count() crashes when queryset contains FilteredRelation
referencing annotation in condition
-+-
   Reporter:  Ben Nace   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 With the following models:

 {{{
 from django.db import models


 class ModelA(models.Model):
 threshold1 = models.PositiveIntegerField()
 threshold2 = models.PositiveIntegerField()


 class ModelB(models.Model):
 model_a = models.ForeignKey(ModelA, on_delete=models.CASCADE)
 value = models.IntegerField()
 }}}

 Attempting the following query results in a FieldError:

 {{{
 from django.db.models import F, FilteredRelation, Q
 ModelA.objects.annotate(combined_threshold=F('threshold1') +
 F('threshold2'), filtered_b=FilteredRelation('modelb',
 
condition=Q(modelb__value__gte=F('combined_threshold'.values('filtered_b__value').count()
 }}}

 {{{
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/query.py", line 608, in count
 return self.query.get_count(using=self.db)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 568, in get_count
 return obj.get_aggregation(using, {"__count": Count("*")})["__count"]
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 554, in get_aggregation
 result = compiler.execute_sql(SINGLE)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/compiler.py", line 1549, in execute_sql
 sql, params = self.as_sql()
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/compiler.py", line 761, in as_sql
 from_, f_params = self.get_from_clause()
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/compiler.py", line 1128, in get_from_clause
 clause_sql, clause_params = self.compile(from_clause)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/compiler.py", line 546, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/datastructures.py", line 105, in as_sql
 extra_sql, extra_params = compiler.compile(self.filtered_relation)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/compiler.py", line 546, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/query_utils.py", line 434, in as_sql
 where = query.build_filtered_relation_q(self.condition,
 reuse=set(self.path))
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 1609, in
 build_filtered_relation_q
 child_clause, _ = self.build_filter(
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 1435, in build_filter
 value = self.resolve_lookup_value(value, can_reuse, allow_joins)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 1204, in
 resolve_lookup_value
 value = value.resolve_expression(
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/expressions.py", line 822, in resolve_expression
 return query.resolve_ref(self.name, allow_joins, reuse, summarize)
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 1976, in resolve_ref
 join_info = self.setup_joins(
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 1823, in setup_joins
 path, final_field, targets, rest = self.names_to_path(
   File "/home/bnace/python-envs/pmcs-42/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 1724, in names_to_path
 raise FieldError(
 django.core.exceptions.FieldError: Cannot resolve keyword
 'combined_threshold' into field. Choices are: __count, filtered_b, id,
 modelb, threshold1, threshold2
 }}}

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

-- 
You received this

Re: [Django] #34930: Parallel tests fail in python 3.11 and 3.12

2023-10-26 Thread Django 
#34930: Parallel tests fail in python 3.11 and 3.12
-+-
 Reporter:  Matt Hegarty |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  pickle   | Triage Stage:
  _contextvars.Context _contextvars  |  Unreviewed
  Context|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matt Hegarty):

 * Attachment "st.txt" added.

 stack trace

-- 
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/0107018b6d1a68dc-2d3eaf71-5d65-4901-b560-ddbc397430f4-00%40eu-central-1.amazonses.com.

[Django] #34930: Parallel tests fail in python 3.11 and 3.12

2023-10-26 Thread Django 
#34930: Parallel tests fail in python 3.11 and 3.12
-+-
   Reporter:  Matt   |  Owner:  nobody
  Hegarty|
   Type:  Bug| Status:  new
  Component:  Testing|Version:  4.2
  framework  |   Keywords:  pickle
   Severity:  Normal |  _contextvars.Context _contextvars
   Triage Stage: |  Context
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Parallel tests work in python3.10 but not in 3.11 or 3.12.  Running tests
 in non-parallel mode works fine.


 {{{
 ./manage.py test --parallel
 }}}


 Error is:


 {{{
 TypeError: cannot pickle '_contextvars.Context' object
 }}}


 See attached stack trace.

 - django 4.2.6

 - python3.10.13 (parallel ok)
 - python3.11.6  (parallel fails)
 - python3.12.0  (parallel fails)

 MacBook Pro Ventura 13.4.1

 Similar to https://code.djangoproject.com/ticket/34010

 The database is Postgres:13 running in a Docker container

-- 
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/0107018b6d1a295b-7e7db809-bb04-47e9-b964-a2566aa2188f-00%40eu-central-1.amazonses.com.

Re: [Django] #34925: refresh_from_db() will not iterate through all of the fields listed in the 'fields' parameter.

2023-10-26 Thread Django 
#34925: refresh_from_db() will not iterate through all of the fields listed in 
the
'fields' parameter.
-+-
 Reporter:  Andrew Cordery   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by trontelj):

 Hello, I'm new to this community, but I have three years of experience
 working with Django, and I'm eager to contribute. Can I work on this
 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/0107018b6d1171bf-a5835bd5-fd0e-4dbf-9854-db624c3460b0-00%40eu-central-1.amazonses.com.

Re: [Django] #34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from Django 2.2.28

2023-10-26 Thread Django 
#34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from 
Django
2.2.28
-+-
 Reporter:  Akash Ilangovan  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  static files,| Triage Stage:
  ManifestStaticFilesStorage |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

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


Comment:

 Hello, thank you for your report!

 I'll be closing this issue as invalid following the
 [https://docs.djangoproject.com/en/4.2/internals/contributing/triaging-
 tickets/#closing-tickets triaging docs], because:

 1. On one hand, Django 2.2.x has been deprecated for more than a year and
 a half, and Django 3.2 is on security-only update mode.
 2. On the other hand, given your custom implementation of
 `StaticFilesStorage`, is unclear how Django (itself) is at fault here.
 Have you tried seeking help in the Django user forum, or in the django-
 storages support channels?

 The best place to get answers to your issue is using any of the user
 support channels from [https://docs.djangoproject.com/en/dev/faq/help
 /#how-do-i-do-x-why-doesn-t-y-work-where-can-i-go-to-get-help this link].

-- 
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/0107018b6cf5d392-a4395a76-c4e8-4ccc-8c8d-15621deb68fd-00%40eu-central-1.amazonses.com.

Re: [Django] #33230: Test client doesn't set explicitly provided Content-Type when data is empty

2023-10-26 Thread Django 
#33230: Test client doesn't set explicitly provided Content-Type when data is 
empty
-+-
 Reporter:  Markus Holtermann|Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 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 Natalia Bidart):

 * status:  assigned => closed
 * resolution:   => wontfix


Comment:

 Hello Anders, thank you for providing additional details.

 I've gone through all the links, and for a while, I found myself diving
 into some non-trivial rabbit holes. However, it was a fun exercise to read
 and investigate this issue. I believe we are in agreement that the HTTP
 spec (RFC 9110) does not require a `Content-Type` header for empty bodies.

 Having said that, I truly appreciate how request validation against an
 OpenAPI spec benefits from always having a `Content-Type` header for map
 indexing. However, if I were implementing a web service that does this, I
 would make it robust enough to handle requests without this header,
 considering that the HTTP spec does not enforce its presence. This could
 involve checking the `Content-Length` first or using another strategy that
 aligns with the specific business logic of the API endpoint.

 The key point here is that, even if we were to change how the Django test
 client behaves, a robust web service should still be able to handle cases
 where the `Content-Type` is missing. After all, there might be other real
 clients out there that do not send it for requests with empty bodies.

 Following that rationale, I think that this is still a `wontfix`. If you
 disagree, the recommended path forward is to first propose and discuss the
 issue with the community and gain consensus to pursue the proposed change.
 To do that, please start a new conversation on the
 [https://forum.djangoproject.com/c/internals/5 Django Forum], where you'll
 reach a wider audience and likely get extra feedback.

 Cheers, Natalia.

-- 
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/0107018b6cda1e3e-c06fd84e-c889-4a3c-900d-a5cd047619eb-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

2023-10-26 Thread Django 
#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Tom
 |  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL   | Triage Stage:  Accepted
  collation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom Carrick):

 * owner:  nobody => Tom Carrick
 * 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/0107018b6ccde50a-620005e3-3360-42f5-9a53-e526ec181459-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

2023-10-26 Thread Django 
#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
--+
 Reporter:  Mariusz Felisiak  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  4.2
 Severity:  Normal|   Resolution:
 Keywords:  PostgreSQL collation  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tom Carrick):

 Interesting. I looked into it and it is indeed only this case that breaks.

 If you add them both at once, it's fine. If you add the collation, then
 the unique, it's fine. But if it's unique, then you try to add the
 collation, boom.

 As you might expect, this also happens for `db_index`.

 However, it doesn't happen when using `Meta` `indexes` / `constraints`
 unless you have `opclasses=["varchar_pattern_ops"]`, and if you remove
 this in the same migration as adding the collation, this also seems to
 work fine (I'm not sure if by luck of because Django first removes the
 constrain, then does other stuff, then adds the constraint purposefully).

 Given that `db_index` is discouraged in the docs... and I'd make the same
 argument for doing the same for `unique=True`, maybe a note in the docs
 about this is enough?

 I didn't look very hard to find a solution, but I think it should be
 possible by adding stuff to
 `django.db.backends.postgresql.schema.DatabaseSchemaEditor._alter_field`.
 I'll take a look.

-- 
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/0107018b6ccdcf5a-04435c73-e4c0-4e85-8e1f-ab3dd90b153a-00%40eu-central-1.amazonses.com.

Re: [Django] #34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from Django 2.2.28

2023-10-26 Thread Django 
#34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from 
Django
2.2.28
-+-
 Reporter:  Akash Ilangovan  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  static files,| Triage Stage:
  ManifestStaticFilesStorage |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Akash Ilangovan:

Old description:

> - Upgraded from Django 2.2.28 to 3.2.
> - Using Django-storage 1.14.2.
> - Replaced CachedFilesMixin with ManifestStaticFilesStorage.
> - Post-upgrade, everything was the same; no other settings changed.
> - Issue: self.location is caching a None value that doesn't alter.
> - Temporary Fix: Deleting the cache in the debugger manually with a del
> statement resolves the issue.
> Code Snippet:
>   {{{#!python
>   class StaticFilesStorage(ManifestStaticFilesStorage, S3Boto3Storage):
> def __init__(self, *args, **kwargs):
> S3Boto3Storage.__init__(self,
> bucket_name=settings.STATIC_FILES_BUCKET,
> custom_domain=domain(settings.STATIC_URL), *args, **kwargs)
> ManifestStaticFilesStorage.__init__(self, *args, **kwargs)
>
>   }}}
> Error output:
> {{{
> File /usr/local/lib/python3.8/dist-
> packages/django/contrib/staticfiles/storage.py:38, in
> StaticFilesStorage.path(self, name)
>  36 def path(self, name):
>  37 if not self.location:
> ---> 38 raise ImproperlyConfigured("You're using the staticfiles
> app "
>  39"without having set the
> STATIC_ROOT "
>  40"setting to a filesystem
> path.")
>  41 return super().path(name)
>
> ImproperlyConfigured: You're using the staticfiles app without having set
> the STATIC_ROOT setting to a filesystem path.
> }}}
> PDB output showing cached None value in self.location:
> {{{
> (Pdb) self.base_location
> 'tmp/vantage/static/'
> (Pdb) self.location
> ''
> (Pdb) os.path.abspath(self.base_location)
> '/app/tmp/vantage/static'
> (Pdb) del self.location
> (Pdb) self.location
> '/app/tmp/vantage/static'
> (Pdb) self._location
> 'tmp/vantage/static/'
> (Pdb) c
> }}}

New description:

 - Upgraded from Django 2.2.28 to 3.2.
 - Using Django-storage 1.14.2.
 - Replaced CachedFilesMixin with ManifestStaticFilesStorage.
 - Post-upgrade, everything was the same; no other settings changed.
 - Issue: self.location is caching a None value that doesn't alter.
 - Temporary Fix: Deleting the cache in the debugger manually with a del
 statement resolves the issue.
 Code Snippet:
   {{{#!python
   class StaticFilesStorage(ManifestStaticFilesStorage, S3Boto3Storage):
 def __init__(self, *args, **kwargs):
 S3Boto3Storage.__init__(self,
 bucket_name=settings.STATIC_FILES_BUCKET,
 custom_domain=domain(settings.STATIC_URL), *args, **kwargs)
 ManifestStaticFilesStorage.__init__(self, *args, **kwargs)

   }}}
 Error output:
 {{{
 File /usr/local/lib/python3.8/dist-
 packages/django/contrib/staticfiles/storage.py:38, in
 StaticFilesStorage.path(self, name)
  36 def path(self, name):
  37 if not self.location:
 ---> 38 raise ImproperlyConfigured("You're using the staticfiles
 app "
  39"without having set the
 STATIC_ROOT "
  40"setting to a filesystem
 path.")
  41 return super().path(name)

 ImproperlyConfigured: You're using the staticfiles app without having set
 the STATIC_ROOT setting to a filesystem path.
 }}}
 PDB output showing cached None value in self.location:
 {{{
 (Pdb) self.base_location
 'tmp/vantage/static/'
 (Pdb) self.location
 ''
 (Pdb) os.path.abspath(self.base_location)
 '/app/tmp/vantage/static'
 (Pdb) del self.location
 (Pdb) self.location
 '/app/tmp/vantage/static'
 (Pdb) self._location
 'tmp/vantage/static/'
 (Pdb) c
 }}}
 The error is resolved after manually refreshing the cache on self.location

--

-- 
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

Re: [Django] #34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from Django 2.2.28

2023-10-26 Thread Django 
#34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from 
Django
2.2.28
-+-
 Reporter:  Akash Ilangovan  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  static files,| Triage Stage:
  ManifestStaticFilesStorage |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Akash Ilangovan:

Old description:

> - Upgraded from Django 2.2.28 to 3.2.
> - Using Django-storage 1.14.2.
> - Replaced CachedFilesMixin with ManifestStaticFilesStorage.
> - Post-upgrade, everything was the same; no other settings changed.
> - Issue: self.location is caching a None value that doesn't alter.
> - Temporary Fix: Deleting the cache in the debugger manually with a del
> statement resolves the issue.
> Code Snippet:
>   {{{#!python
>   class StaticFilesStorage(ManifestStaticFilesStorage, S3Boto3Storage):
> def __init__(self, *args, **kwargs):
> S3Boto3Storage.__init__(self,
> bucket_name=settings.STATIC_FILES_BUCKET,
> custom_domain=domain(settings.STATIC_URL), *args, **kwargs)
> ManifestStaticFilesStorage.__init__(self, *args, **kwargs)
>
>   }}}
> }}}
> PDB output showing cached None value in self.location:
> {{{
> (Pdb) self.base_location
> 'tmp/vantage/static/'
> (Pdb) self.location
> ''
> (Pdb) os.path.abspath(self.base_location)
> '/app/tmp/vantage/static'
> (Pdb) del self.location
> (Pdb) self.location
> '/app/tmp/vantage/static'
> (Pdb) self._location
> 'tmp/vantage/static/'
> (Pdb) c
> }}}

New description:

 - Upgraded from Django 2.2.28 to 3.2.
 - Using Django-storage 1.14.2.
 - Replaced CachedFilesMixin with ManifestStaticFilesStorage.
 - Post-upgrade, everything was the same; no other settings changed.
 - Issue: self.location is caching a None value that doesn't alter.
 - Temporary Fix: Deleting the cache in the debugger manually with a del
 statement resolves the issue.
 Code Snippet:
   {{{#!python
   class StaticFilesStorage(ManifestStaticFilesStorage, S3Boto3Storage):
 def __init__(self, *args, **kwargs):
 S3Boto3Storage.__init__(self,
 bucket_name=settings.STATIC_FILES_BUCKET,
 custom_domain=domain(settings.STATIC_URL), *args, **kwargs)
 ManifestStaticFilesStorage.__init__(self, *args, **kwargs)

   }}}
 Error output:
 {{{
 File /usr/local/lib/python3.8/dist-
 packages/django/contrib/staticfiles/storage.py:38, in
 StaticFilesStorage.path(self, name)
  36 def path(self, name):
  37 if not self.location:
 ---> 38 raise ImproperlyConfigured("You're using the staticfiles
 app "
  39"without having set the
 STATIC_ROOT "
  40"setting to a filesystem
 path.")
  41 return super().path(name)

 ImproperlyConfigured: You're using the staticfiles app without having set
 the STATIC_ROOT setting to a filesystem path.
 }}}
 PDB output showing cached None value in self.location:
 {{{
 (Pdb) self.base_location
 'tmp/vantage/static/'
 (Pdb) self.location
 ''
 (Pdb) os.path.abspath(self.base_location)
 '/app/tmp/vantage/static'
 (Pdb) del self.location
 (Pdb) self.location
 '/app/tmp/vantage/static'
 (Pdb) self._location
 'tmp/vantage/static/'
 (Pdb) c
 }}}

--

-- 
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/0107018b6cc8545b-7fe3d2f7-2f27-47ab-aaaf-7ffce786e3ed-00%40eu-central-1.amazonses.com.

[Django] #34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from Django 2.2.28

2023-10-26 Thread Django 
#34929: Issue with Django 3.2 and Django-storage 1.14.2 after Upgrading from 
Django
2.2.28
-+-
   Reporter:  akash- |  Owner:  nobody
  vantage|
   Type:  Bug| Status:  new
  Component:  Utilities  |Version:  3.2
   Severity:  Normal |   Keywords:  static files,
   Triage Stage: |  ManifestStaticFilesStorage
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 - Upgraded from Django 2.2.28 to 3.2.
 - Using Django-storage 1.14.2.
 - Replaced CachedFilesMixin with ManifestStaticFilesStorage.
 - Post-upgrade, everything was the same; no other settings changed.
 - Issue: self.location is caching a None value that doesn't alter.
 - Temporary Fix: Deleting the cache in the debugger manually with a del
 statement resolves the issue.
 Code Snippet:
   {{{#!python
   class StaticFilesStorage(ManifestStaticFilesStorage, S3Boto3Storage):
 def __init__(self, *args, **kwargs):
 S3Boto3Storage.__init__(self,
 bucket_name=settings.STATIC_FILES_BUCKET,
 custom_domain=domain(settings.STATIC_URL), *args, **kwargs)
 ManifestStaticFilesStorage.__init__(self, *args, **kwargs)

   }}}
 }}}
 PDB output showing cached None value in self.location:
 {{{
 (Pdb) self.base_location
 'tmp/vantage/static/'
 (Pdb) self.location
 ''
 (Pdb) os.path.abspath(self.base_location)
 '/app/tmp/vantage/static'
 (Pdb) del self.location
 (Pdb) self.location
 '/app/tmp/vantage/static'
 (Pdb) self._location
 'tmp/vantage/static/'
 (Pdb) c
 }}}

-- 
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/0107018b6cc61a66-eeb48fb7-71ff-40e9-a16a-3df5e00dd4bd-00%40eu-central-1.amazonses.com.

Re: [Django] #34928: makemigrations when adding a ForeignKey to a model with a UniqueConstraint must create the field before creating the constraint

2023-10-26 Thread Django 
#34928: makemigrations when adding a ForeignKey to a model with a 
UniqueConstraint
must create the field before creating the constraint
+--
 Reporter:  yonatanramirez  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  4.2
 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 Mariusz Felisiak):

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


Comment:

 Duplicate of #34333, fixed in 4b1bfea2846f66f504265cec46ee1fe94ee9c98b
 (Django 5.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/0107018b6ca9a3d4-bba82d75-fefa-4c25-9d3b-9db2c9265c8e-00%40eu-central-1.amazonses.com.

[Django] #34928: makemigrations when adding a ForeignKey to a model with a UniqueConstraint must create the field before creating the constraint

2023-10-26 Thread Django 
#34928: makemigrations when adding a ForeignKey to a model with a 
UniqueConstraint
must create the field before creating the constraint
--+
   Reporter:  yonatanramirez  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  4.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   |
--+
 This issue looks like #25551 but with UniqueConstraint and not
 unique_together.


 {{{#!diff
 from django.db import models

 +class Author(models.Model):
 +name = models.CharField(max_length=255)
 +
  class Book(models.Model):
  name = models.CharField(max_length=255)
 +author = models.ForeignKey(Author, on_delete=models.CASCADE,
 null=True)
 +
 +class Meta:
 +constraints = [
 +models.UniqueConstraint(
 +fields=['name', 'author'],
 +name='unique_book_name_author'
 +)
 +]
 }}}

 This is the output of the makemigration command
 {{{
 Migrations for 'issue':
   issue/migrations/0002_author_book_unique_book_name_author_book_author.py
 - Create model Author
 - Create constraint unique_book_name_author on model book
 - Add field author to book
 }}}

 And the portion of the migration file:
 {{{
 operations = [
 migrations.CreateModel(
 name='Author',
 fields=[
 ('id', models.BigAutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('name', models.CharField(max_length=255)),
 ],
 ),
 migrations.AddConstraint(
 model_name='book',
 constraint=models.UniqueConstraint(fields=('name', 'author'),
 name='unique_book_name_author'),
 ),
 migrations.AddField(
 model_name='book',
 name='author',
 field=models.ForeignKey(null=True,
 on_delete=django.db.models.deletion.CASCADE, to='issue.author'),
 ),
 ]
 }}}

 The stacktrace:
 {{{
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, issue, sessions
 Running migrations:
   Applying contenttypes.0001_initial... OK
   Applying auth.0001_initial... OK
   Applying admin.0001_initial... OK
   Applying admin.0002_logentry_remove_auto_add... OK
   Applying admin.0003_logentry_add_action_flag_choices... OK
   Applying contenttypes.0002_remove_content_type_name... OK
   Applying auth.0002_alter_permission_name_max_length... OK
   Applying auth.0003_alter_user_email_max_length... OK
   Applying auth.0004_alter_user_username_opts... OK
   Applying auth.0005_alter_user_last_login_null... OK
   Applying auth.0006_require_contenttypes_0002... OK
   Applying auth.0007_alter_validators_add_error_messages... OK
   Applying auth.0008_alter_user_username_max_length... OK
   Applying auth.0009_alter_user_last_name_max_length... OK
   Applying auth.0010_alter_group_name_max_length... OK
   Applying auth.0011_update_proxy_permissions... OK
   Applying auth.0012_alter_user_first_name_max_length... OK
   Applying issue.0001_initial... OK
   Applying
 issue.0002_author_book_unique_book_name_author_book_author...Traceback
 (most recent call last):
   File "/home/yramirez/.pyenv/versions/django/lib/python3.11/site-
 packages/django/db/models/options.py", line 681, in get_field
 return self.fields_map[field_name]
~~~
 KeyError: 'author'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/yramirez/playground/django/essai/manage.py", line 22, in
 
 main()
   File "/home/yramirez/playground/django/essai/manage.py", line 18, in
 main
 execute_from_command_line(sys.argv)
   File "/home/yramirez/.pyenv/versions/django/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 442, in
 execute_from_command_line
 utility.execute()
   File "/home/yramirez/.pyenv/versions/django/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 436, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/yramirez/.pyenv/versions/django/lib/python3.11/site-
 packages/django/core/management/base.py", line 412, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/yramirez/.pyenv/versions/django/lib/python3.11/site-
 packages/django/core/management/base.py", line 458, in execute
 output = self.handle(*args, **options)
  ^
   File "/home/yramirez/.pyenv/versions/django/lib/python3.11/site-

Re: [Django] #10743: Support lookup separators in ModelAdmin.list_display

2023-10-26 Thread Django 
#10743: Support lookup separators in ModelAdmin.list_display
-+-
 Reporter:  mrts |Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  efficient-admin, | Triage Stage:  Accepted
  list_display   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


Comment:

 Marking as needs improvement per Natalia's
 [https://github.com/django/django/pull/17357#issuecomment-1779734651
 comment].

-- 
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/0107018b6b9c918a-daa77fc8-1930-49b1-bc76-3d170e3d295e-00%40eu-central-1.amazonses.com.

Re: [Django] #10941: Add a templatetag to generate querystrings

2023-10-26 Thread Django 
#10941: Add a templatetag to generate querystrings
-+-
 Reporter:  Ben Spaulding|Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  pagination   | 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 Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"e67d3580edbee1a4b58d40875293714ac3fc6937" e67d3580]:
 {{{
 #!CommitTicketReference repository=""
 revision="e67d3580edbee1a4b58d40875293714ac3fc6937"
 Fixed #10941 -- Added {% query_string %} template tag.
 }}}

-- 
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/0107018b6b66f5b4-078addf9-7d8e-4317-a680-2d5c5625b93e-00%40eu-central-1.amazonses.com.

Re: [Django] #34925: refresh_from_db() will not iterate through all of the fields listed in the 'fields' parameter.

2023-10-26 Thread Django 
#34925: refresh_from_db() will not iterate through all of the fields listed in 
the
'fields' parameter.
-+-
 Reporter:  Andrew Cordery   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by David Sanders):

 Hi Andrew,

 Thanks for you investigation, interested in submitting a patch & test? 

-- 
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/0107018b6b13eb7a-cd17c437-925b-4361-82bb-826d80a626be-00%40eu-central-1.amazonses.com.

Re: [Django] #10941: Add a templatetag to generate querystrings

2023-10-26 Thread Django 
#10941: Add a templatetag to generate querystrings
-+-
 Reporter:  Ben Spaulding|Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | 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 Mariusz Felisiak):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018b6afc194e-e9d13349-2151-442b-b990-a52c670432fd-00%40eu-central-1.amazonses.com.