date:20230721

Re: [Django] #31300: Add function-based virtual fields.

2023-07-21 Thread Django

#31300: Add function-based virtual fields.
-+-
 Reporter:  Dulmandakh   |Owner:  Jeremy
 |  Nauta
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  field, database, | Triage Stage:  Ready for
  generated  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jeremy Nauta):

 * 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/010701897b21a29a-8c06f84c-df43-4781-b2d6-9d72fed99fe2-00%40eu-central-1.amazonses.com.

Re: [Django] #34733: m2m_changed signal is unaware if .set() method is being called

2023-07-21 Thread Django

#34733: m2m_changed signal is unaware if .set() method is being called
-+-
 Reporter:  lekjos   |Owner:  lekjos
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lekjos):

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


Old description:

> When a `related_m2m_field.set()` method is called, the `m2m_changed`
> signal is fired four times for action: `pre_remove`, `post_remove`,
> `pre_add`, and `post_add` (or `pre_clear` / `post_clear`).
>
> This poses a problem if the signal is supposed to run validation on the
> final state of the model. For example, let's say I have a model called
> `Customer` with a many-to-many relation to `SubscriptionPlan` and I have
> a `m2m_changed` signal that is supposed to validate if their
> SubscriptionPlan is valid.
>
> If I call `subscription_plans.set([some_plans])`, the many-to-many
> manager will first call `subscription_plans.remove()` then `.add()`
> inside an atomic transaction. If my signal validates on the first
> `remove()`, it could be in an invalid state, even though it won't be by
> the time the `.add()` completes.
>
> To get around this, I had to create a custom ManyToManyField with a
> custom RelatedManager that set an instance variable on the model when the
> `.set()` method was called. I'd like to propose adding a feature to the
> RelatedManager or to the signals to make the `m2m_changed` signal aware
> of if the `.set()` method was called when running. This could be a
> private attribute on the instance or extra information passed to the
> signal receiver.
>
> If this feature already exists or there's a decent workaround, let me
> know and i'll close the ticket! Otherwise, I have a patch in mind that I
> can raise a PR for and attach.

New description:

 When a `related_m2m_field.set()` method is called, the `m2m_changed`
 signal is fired four times for action: `pre_remove`, `post_remove`,
 `pre_add`, and `post_add` (or `pre_clear` / `post_clear`).

 This poses a problem if the signal is supposed to run validation on the
 final state of the model. For example, let's say I have a model called
 `Customer` with a many-to-many relation to `SubscriptionPlan` and I have a
 `m2m_changed` signal that is supposed to validate if their
 SubscriptionPlan is valid.

 If I call `Customer.subscription_plans.set([some_plans])`, the many-to-
 many manager will first call `subscription_plans.remove()` then `.add()`
 inside an atomic transaction. If my signal validates on the first
 `.remove()`, it could be in an invalid state, even though it won't be by
 the time the `.add()` completes. However, I still need to be able to
 validate on the signal if the standard `.remove()` method is called.

 To get around this, I had to create a custom ManyToManyField with a custom
 RelatedManager that set an instance variable on the model when the
 `.set()` method was called. I'd like to propose adding a feature to the
 RelatedManager or to the signals to make the `m2m_changed` signal aware of
 if the `.set()` method was called when running. This could be a private
 attribute on the instance or extra information passed to the signal
 receiver.

 If this feature already exists or there's a decent workaround, let me know
 and i'll close the ticket! Otherwise, I have a patch in mind that I can
 raise a PR for and attach.

--

-- 
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/010701897aabd72d-9cd38089-b857-48dd-a2d4-eb0d7f72f25a-00%40eu-central-1.amazonses.com.

[Django] #34733: m2m_changed signal is unaware if .set() method is being called

2023-07-21 Thread Django

#34733: m2m_changed signal is unaware if .set() method is being called
-+-
Reporter: lekjos | Owner: nobody
Type: New| Status: new
feature|
Component: Database |Version: dev
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 |
-+-
When a `related_m2m_field.set()` method is called, the `m2m_changed`
signal is fired four times for action: `pre_remove`, `post_remove`,
`pre_add`, and `post_add` (or `pre_clear` / `post_clear`).

This poses a problem if the signal is supposed to run validation on the
final state of the model. For example, let's say I have a model called
`Customer` with a many-to-many relation to `SubscriptionPlan` and I have a
`m2m_changed` signal that is supposed to validate if their
SubscriptionPlan is valid.

If I call `subscription_plans.set([some_plans])`, the many-to-many manager
will first call `subscription_plans.remove()` then `.add()` inside an
atomic transaction. If my signal validates on the first `remove()`, it
could be in an invalid state, even though it won't be by the time the
`.add()` completes.

To get around this, I had to create a custom ManyToManyField with a custom
RelatedManager that set an instance variable on the model when the
`.set()` method was called. I'd like to propose adding a feature to the
RelatedManager or to the signals to make the `m2m_changed` signal aware of
if the `.set()` method was called when running. This could be a private
attribute on the instance or extra information passed to the signal
receiver.

If this feature already exists or there's a decent workaround, let me know
and i'll close the ticket! Otherwise, I have a patch in mind that I can
raise a PR for and attach.

--
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/010701897aa4eb79-e64e93d0-2dde-418d-94ee-6d45e4c9b0e7-00%40eu-central-1.amazonses.com.

Re: [Django] #31700: Highlight destructive operations in makemigrations output

2023-07-21 Thread Django

#31700: Highlight destructive operations in makemigrations output
-+---
 Reporter:  Tom Forbes   |Owner:  Amir Karimi
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by Amir Karimi):

 * owner:  (none) => Amir Karimi
 * status:  new => assigned


Comment:

 I'd like to work on this issue. I have implemented it in the +/-/~ way. I
 can add coloring too. I'll create its PR soon.

-- 
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/010701897a9b1610-77b08a65-f9ff-40f5-a682-f133f8f54799-00%40eu-central-1.amazonses.com.

Re: [Django] #34732: UnicodeEncodeError on two tests in Python 3.12

2023-07-21 Thread Django

#34732: UnicodeEncodeError on two tests in Python 3.12
-+-
 Reporter:  Michel Alexandre |Owner:  nobody
  Salim  |
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  dev
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michel Alexandre Salim):

 Thanks! Yeah, I was just debugging with breakpoint() and realized it's
 getaddresses that now returns `[('', '')]` as you noted

-- 
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/0107018979fcffb4-a1dc7572-4b34-4aa6-a2f9-7a785e22e621-00%40eu-central-1.amazonses.com.

Re: [Django] #34732: UnicodeEncodeError on two tests in Python 3.12

2023-07-21 Thread Django

#34732: UnicodeEncodeError on two tests in Python 3.12
-+-
 Reporter:  Michel Alexandre |Owner:  nobody
  Salim  |
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  dev
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 This not an issue in Django, but a regression in Python 3.12.0b4, check
 out https://github.com/python/cpython/issues/106669.

-- 
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/0107018979f3ddaf-fb320614-c9e5-49ca-8c50-134aac73c425-00%40eu-central-1.amazonses.com.

[Django] #34732: UnicodeEncodeError on two tests in Python 3.12

2023-07-21 Thread Django

#34732: UnicodeEncodeError on two tests in Python 3.12
--+
   Reporter:  Michel Alexandre Salim  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |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   |
--+
 When running the tests inside a virtual environment with Fedora 39's
 python3-3.12.0~b4-1.fc39.x86_64, there are currently two test failures
 left with the `test_sqlite` backend


 {{{
 ==
 ERROR: test_safe_mime_multipart
 (mail.tests.MailTests.test_safe_mime_multipart)
 Make sure headers can be set with a different encoding than utf-8 in
 --
 Traceback (most recent call last):
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 64, in forbid_multi_line_headers
 val.encode("ascii")
 UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in
 position 2: ordinal not in range(128)

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/michel/src/github/django/django/tests/mail/tests.py", line
 504, in test_safe_mime_multipart
 msg.message()["To"],
 ^
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 266, in message
 self._set_list_header_if_not_empty(msg, "To", self.to)
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 431, in _set_list_header_if_not_empty
 msg[header] = value
 ~~~
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 188, in __setitem__
 name, val = forbid_multi_line_headers(name, val, self.encoding)
 ^^^
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 67, in forbid_multi_line_headers
 val = ", ".join(
   ^^
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 68, in 
 sanitize_address(addr, encoding) for addr in getaddresses((val,))
 
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 101, in sanitize_address
 raise ValueError(f'Invalid address "{address}"')
 ValueError: Invalid address ""

 ==
 ERROR: test_unicode_address_header
 (mail.tests.MailTests.test_unicode_address_header)
 Regression for #11144 - When a to/from/cc header contains Unicode,
 --
 Traceback (most recent call last):
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 64, in forbid_multi_line_headers
 val.encode("ascii")
 UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in
 position 2: ordinal not in range(128)

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/michel/src/github/django/django/tests/mail/tests.py", line
 461, in test_unicode_address_header
 email.message()["To"],
 ^^^
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 266, in message
 self._set_list_header_if_not_empty(msg, "To", self.to)
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 431, in _set_list_header_if_not_empty
 msg[header] = value
 ~~~
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 165, in __setitem__
 name, val = forbid_multi_line_headers(name, val, self.encoding)
 ^^^
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 67, in forbid_multi_line_headers
 val = ", ".join(
   ^^
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 68, in 
 sanitize_address(addr, encoding) for addr in getaddresses((val,))
 
   File
 "/home/michel/src/github/django/django/django/core/mail/message.py", line
 101, in sanitize_address
 raise ValueError(f'Invalid address "{address}"')
 ValueError: Invalid address ""

 }}}

-- 
Ticket URL: 
Django

Re: [Django] #34118: Python 3.12 compatibility

2023-07-21 Thread Django

#34118: Python 3.12 compatibility
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"62b83889e066b8270854f7560e0498944efd7689" 62b83889]:
 {{{
 #!CommitTicketReference repository=""
 revision="62b83889e066b8270854f7560e0498944efd7689"
 Fixed #34731, Refs #34118 -- Replaced assertEquals() with assertEqual() in
 test_condition_with_func_and_lookup_outside_relation_name().

 Signed-off-by: Michel Alexandre Salim 
 }}}

-- 
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/0107018979e3a7a9-e6aa4527-fbe9-4552-b2cc-fbfa88c9408c-00%40eu-central-1.amazonses.com.

Re: [Django] #34731: Django test suite still has an occurence of assertEquals, removed in Python 3.12

2023-07-21 Thread Django

#34731: Django test suite still has an occurence of assertEquals, removed in 
Python
3.12
-+-
 Reporter:  michel-slm   |Owner:  michel-
 |  slm
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  dev
 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
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"62b83889e066b8270854f7560e0498944efd7689" 62b83889]:
 {{{
 #!CommitTicketReference repository=""
 revision="62b83889e066b8270854f7560e0498944efd7689"
 Fixed #34731, Refs #34118 -- Replaced assertEquals() with assertEqual() in
 test_condition_with_func_and_lookup_outside_relation_name().

 Signed-off-by: Michel Alexandre Salim 
 }}}

-- 
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/0107018979e3a773-eaca0a2a-177e-4aa4-99f0-6b8e6ab18430-00%40eu-central-1.amazonses.com.

Re: [Django] #34655: Tests for RadioSelect and Select have diverged considerably, potentially leaving RadioSelect undertested

2023-07-21 Thread Django

#34655: Tests for RadioSelect and Select have diverged considerably, potentially
leaving RadioSelect undertested
-+-
 Reporter:  Natalia Bidart   |Owner:  Jacob1507
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Forms|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Faishal manzar => Jacob1507
 * needs_better_patch:  1 => 0


Comment:

 As far as I'm aware, it's waiting for another review by 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/0107018979dd4171-57010504-1acb-4f7b-8fe6-f7c98ae0b045-00%40eu-central-1.amazonses.com.

Re: [Django] #34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL index operations

2023-07-21 Thread Django

#34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL
index
operations
--+--
Reporter: Laurent Tramoy|Owner: (none)
Type: New feature | Status: closed
Component: contrib.postgres | Version: 4.2
Severity: Normal| Resolution: wontfix
Keywords:| Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
--+--
Changes (by Mariusz Felisiak):

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

Comment:

I still think it is a bad idea for exactly the same reasons I already
mentioned in the #34298. Also, I don't think that separate operations or
extra arguments to control this behavior is a good idea, following this
path we could add the same to all migration operations. Why should index
creation be treated differently? Last but not least this syntax is not
supported by all database engines with built-in backends.

Please first start a discussion on the DevelopersMailingList, where you'll
reach a wider audience and see what other think, and
[https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
tickets/#closing-tickets follow the triaging guidelines with regards to
wontfix tickets.

--
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/0107018979d31574-71f793cf-b741-4a59-9d4a-5dd422570dcc-00%40eu-central-1.amazonses.com.

Re: [Django] #34731: Django test suite still has an occurence of assertEquals, removed in Python 3.12

2023-07-21 Thread Django

#34731: Django test suite still has an occurence of assertEquals, removed in 
Python
3.12
-+-
 Reporter:  Michel Alexandre |Owner:  Michel
  Salim  |  Alexandre Salim
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/0107018979cb44ad-9860c821-613c-4421-afc4-e411ea547b13-00%40eu-central-1.amazonses.com.

Re: [Django] #34731: Django test suite still has an occurence of assertEquals, removed in Python 3.12

2023-07-21 Thread Django

#34731: Django test suite still has an occurence of assertEquals, removed in 
Python
3.12
---+--
 Reporter:  michel-slm |Owner:  michel-slm
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  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 Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Good catch, my bad.

-- 
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/0107018979c5e688-beda51b9-eb6a-4297-a4f5-611a26cf226a-00%40eu-central-1.amazonses.com.

Re: [Django] #34731: Django test suite still has an occurence of assertEquals, removed in Python 3.12

2023-07-21 Thread Django

#34731: Django test suite still has an occurence of assertEquals, removed in
Python
3.12
---+--
Reporter: michel-slm |Owner: michel-slm
Type: Bug| Status: assigned
Component: Testing framework | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
---+--
Description changed by michel-slm:

Old description:

> Python 3.12, shipping in the upcoming Fedora 39, finally removed the
> deprecated `assertEquals` in favor of `assertEqual`. The Django test
> suite mostly use the latter already, but there is one occurence of the
> former left. It should be converted.

New description:

Python 3.12, shipping in the upcoming Fedora 39, finally removed the
deprecated `assertEquals` in favor of `assertEqual`. The Django test suite
mostly use the latter already, but there is one occurence of the former
left. It should be converted.

Test failure on Python 3.12:

{{{
==
ERROR: test_condition_with_func_and_lookup_outside_relation_name
(filtered_relation.tests.FilteredRelationTests.test_condition_with_
func_and_lookup_outside_relation_name)
--
Traceback (most recent call last):
File
"/home/michel/src/github/django/django/tests/filtered_relation/tests.py",
line 652, in test_condition_with_func_and_lookup_ou
tside_relation_name
self.assertEquals(qs.count(), 1)
^
AttributeError: 'FilteredRelationTests' object has no attribute
'assertEquals'. Did you mean: 'assertEqual'?

}}}

--
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/0107018979c4b694-3600bbe3-9a8b-4743-9487-1e532b65d31b-00%40eu-central-1.amazonses.com.

Re: [Django] #34731: Django test suite still has an occurence of assertEquals, removed in Python 3.12

2023-07-21 Thread Django

#34731: Django test suite still has an occurence of assertEquals, removed in 
Python
3.12
---+--
 Reporter:  michel-slm |Owner:  michel-slm
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by michel-slm):

 * owner:  nobody => michel-slm
 * status:  new => assigned


Comment:

 PR: https://github.com/django/django/pull/17103

-- 
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/0107018979c35280-08827800-2ac7-42ed-92ee-385174848dba-00%40eu-central-1.amazonses.com.

[Django] #34731: Django test suite still has an occurence of assertEquals, removed in Python 3.12

2023-07-21 Thread Django

#34731: Django test suite still has an occurence of assertEquals, removed in 
Python
3.12
-+
   Reporter:  michel-slm |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  dev
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Python 3.12, shipping in the upcoming Fedora 39, finally removed the
 deprecated `assertEquals` in favor of `assertEqual`. The Django test suite
 mostly use the latter already, but there is one occurence of the former
 left. It should be converted.

-- 
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/0107018979bf8f47-d2427636-d35e-457e-ba09-b7141c1e79b6-00%40eu-central-1.amazonses.com.

Re: [Django] #34586: create() does not save reverse OneToOne relationship nor raise an Exception

2023-07-21 Thread Django

#34586: create() does not save reverse OneToOne relationship nor raise an 
Exception
-+-
 Reporter:  Alan Rivas   |Owner:  Mariana
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariana):

 * owner:  (none) => Mariana
 * 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/010701897919178e-fda0840e-e7cb-49c2-83da-4bad8d1a6c3b-00%40eu-central-1.amazonses.com.

Re: [Django] #34586: create() does not save reverse OneToOne relationship nor raise an Exception

2023-07-21 Thread Django

#34586: create() does not save reverse OneToOne relationship nor raise an 
Exception
-+-
 Reporter:  Alan Rivas   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariana):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701897918f34a-bd4544f2-8576-4c0a-8056-24e918cfcf27-00%40eu-central-1.amazonses.com.

Re: [Django] #34699: Filtering on annotated TruncSecond expression gives unexpected result.

2023-07-21 Thread Django

#34699: Filtering on annotated TruncSecond expression gives unexpected result.
-+-
 Reporter:  Stefan   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Francesco Panico):

 * owner:  Francesco Panico => (none)
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018978e1fe0c-b5187c95-808a-47c0-a2e7-e2e28c6bb1c5-00%40eu-central-1.amazonses.com.

Re: [Django] #34730: Add an assertMessages assertion

2023-07-21 Thread Django

#34730: Add an assertMessages assertion
---+--
 Reporter:  François Freitag   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by François Freitag:

Old description:

> Most projects I’ve worked on used the messages framework, and many of
> them were repeating some boilerplate in the form described in
> https://stackoverflow.com/questions/2897609/how-can-i-unit-test-django-
> messages.
>
> {{{#!python
> from django.contrib.messages import get_messages
>
> messages = list(get_messages(response.wsgi_request))
> self.assertEqual(len(messages), 1)
> self.assertEqual(str(messages[0]), 'my message')
> }}}
>

> I see several small pain points in this code:
> - accessing `response.wsgi_request`, because get_messages needs a
> `request` but all we have is a response.
> - `get_messages` returns an iterator, that must be consumed to perform
> assertions, hence the casting to a list
> - the expectation lacks precision (missing the level) and clarity
> - it’s boilerplate-ish
>

> Maybe adding an assertion to facilitate this test would benefit the other
> projects.
>
> The code is small enough that it won’t be worth pulling down as a 3rd
> party package, especially since it requires changing the base test class
> over the entire test suite.

New description:

 Most projects I’ve worked on used the messages framework, and many of them
 were repeating some boilerplate in the form described in
 https://stackoverflow.com/questions/2897609/how-can-i-unit-test-django-
 messages.

 {{{#!python
 from django.contrib.messages import get_messages

 messages = list(get_messages(response.wsgi_request))
 self.assertEqual(len(messages), 1)
 self.assertEqual(str(messages[0]), 'my message')
 }}}


 I see several small pain points in this code:
 - accessing `response.wsgi_request`, because get_messages needs a
 `request` but all we have is a response.
 - `get_messages` returns an iterator, that must be consumed to perform
 assertions, hence the casting to a list
 - the expectation lacks precision (missing the level) and clarity (in
 intent, and when failures are reported)
 - it’s boilerplate-ish


 Maybe adding an assertion to facilitate this test would benefit the other
 projects.

 The code is small enough that it won’t be worth pulling down as a 3rd
 party package, especially since it requires changing the base test class
 over the entire test suite.

--

-- 
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/0107018978b32b41-04b9c7c7-0877-47ba-be1c-013b13e8f15a-00%40eu-central-1.amazonses.com.

Re: [Django] #34730: Add an assertMessages assertion

2023-07-21 Thread Django

#34730: Add an assertMessages assertion
---+--
 Reporter:  François Freitag   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by François Freitag):

 PR : https://github.com/django/django/pull/17101

-- 
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/0107018978b16971-1f59deef-b11f-4b3f-a8b2-7099206c08a4-00%40eu-central-1.amazonses.com.

[Django] #34730: Add an assertMessages assertion

2023-07-21 Thread Django

#34730: Add an assertMessages assertion
-+
   Reporter:  François Freitag   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |Version:  dev
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Most projects I’ve worked on used the messages framework, and many of them
 were repeating some boilerplate in the form described in
 https://stackoverflow.com/questions/2897609/how-can-i-unit-test-django-
 messages.

 {{{#!python
 from django.contrib.messages import get_messages

 messages = list(get_messages(response.wsgi_request))
 self.assertEqual(len(messages), 1)
 self.assertEqual(str(messages[0]), 'my message')
 }}}


 I see several small pain points in this code:
 - accessing `response.wsgi_request`, because get_messages needs a
 `request` but all we have is a response.
 - `get_messages` returns an iterator, that must be consumed to perform
 assertions, hence the casting to a list
 - the expectation lacks precision (missing the level) and clarity
 - it’s boilerplate-ish


 Maybe adding an assertion to facilitate this test would benefit the other
 projects.

 The code is small enough that it won’t be worth pulling down as a 3rd
 party package, especially since it requires changing the base test class
 over the entire test suite.

-- 
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/0107018978b138d9-cf732ef8-a956-4565-bbb7-49d24d84c3e1-00%40eu-central-1.amazonses.com.

[Django] #34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL index operations

2023-07-21 Thread Django

#34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL 
index
operations
+
   Reporter:  Laurent Tramoy|  Owner:  (none)
   Type:  New feature   | Status:  new
  Component:  contrib.postgres  |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 |
+
 Hello,

 I'd like to be able to add a `IF NOT EXISTS` clause when creating indexes
 (both with AddIndex and AddIndexConcurrently).

 I've read this ticket https://code.djangoproject.com/ticket/34298 where
 Mariusz considers it's a bad idea (for constraints), and I get his point,
 however I've a few counter arguments:
 * I feel like the workflow "add an index in a deployed environment /
 check it works as expected / add it to Django code" is quite common in
 "real-life" applications, for now we have to write a custom
 `SeparateDatabaseAndState` each time we do this
 * The idea would be to enable this explicitly (either by adding a
 `AddIndexIfNotExists` operation, or by adding a parameter to `AddIndex` /
 `AddIndexConcurrently`), so people should know what they're doing when
 using this.
 * The `IF EXISTS` clause is already used  when dropping the index, it
 would be more consistent to be able to allow it when adding the index too
 
[https://github.com/django/django/blob/afc880571d5f5a16b977070b15014f9583524898/django/db/backends/postgresql/schema.py#L25]

-- 
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/010701897868dd71-583f0cb7-0f1b-4f0f-8ea7-6f349e5be731-00%40eu-central-1.amazonses.com.

Re: [Django] #34723: `TypeError` when loading a Django app with incorrect type of `choices`

2023-07-21 Thread Django

Comment (by Natalia Bidart):

Replying to [comment:1 Mariusz Felisiak]:
> > I believe that the code in `Field.get_choices` could be a little more
robust, so exceptions are not raised on incorrect choices type.
>
> I'm not sure it's worth changing, it's clearly user error that's easy to
notice, understand, and fix. Furthermore, there are other places that
assume `choices` is iterable (e.g. `flatchoices`). Are we going to add
protection to all of them? You can find many such edge cases in Django
source code, when a type is assumed. IMO, we don't need to be
overprotective. Especially since this is already covered by a system
check.

Fair enough!

> > Ideally we'd let the check framework run and report these issues is a
friendlier manner.

Right, my point is that the check framework never reports this issue (not
even on first start) because Django crashes before the checks are run.

> Autoreloader cannot run checks after each change, this would have bad
impact on developers experience. We even added an option to not run checks
even once, check out #32296.

Thanks for the pointer, though note that it seems that system checks are
run on every reload (if no special option is passed):

{{{
(djangodev) [nessita@socrates projectfromrepo]$ python -Wall manage.py
runserver 0.0.0.0:9000
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
July 21, 2023 - 13:36:06
Django version 5.0.dev20230720170441, using settings
'projectfromrepo.settings'
Starting development server at http://0.0.0.0:9000/
Quit the server with CONTROL-C.

/home/nessita/fellowship/projectfromrepo/ticket_34711/models.py changed,
reloading.
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
July 21, 2023 - 13:36:22
Django version 5.0.dev20230720170441, using settings
'projectfromrepo.settings'
Starting development server at http://0.0.0.0:9000/
Quit the server with CONTROL-C.

/home/nessita/fellowship/projectfromrepo/ticket_34711/models.py changed,
reloading.
Watching for file changes with StatReloader
Performing system checks...

Exception in thread django-main-thread:
Traceback (most recent call last):
File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
self.run()
File "/usr/lib/python3.11/threading.py", line 975, in run
self._target(*self._args, **self._kwargs)
File "/home/nessita/fellowship/django/django/utils/autoreload.py", line
64, in wrapper
fn(*args, **kwargs)
File
"/home/nessita/fellowship/django/django/core/management/commands/runserver.py",
line 133, in inner_run
self.check(display_num_errors=True)
File "/home/nessita/fellowship/django/django/core/management/base.py",
line 556, in check
raise SystemCheckError(msg)
django.core.management.base.SystemCheckError: SystemCheckError: System
check identified some issues:

ERRORS:
ticket_34711.OtherTestModel.asset2: (fields.E009) 'max_length' is too
small to fit the longest value in 'choices' (4 characters).

System check identified 1 issue (0 silenced).
}}}

See all the `Performing system checks` when a file is changed. I'm not
arguing the ticket resolution, I just thought it'd be nice to not have
Django crashing before even running the checks, but I agree the reported
crash is clear and easily fixable.

--
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/01070189784b16a2-50d62648-b82c-4dbb-88aa-f15d9f7f2c50-00%40eu-central-1.amazonses.com.

Re: [Django] #34728: OR operator on queryset does not work as expected

2023-07-21 Thread Django

#34728: OR operator on queryset does not work as expected
-+-
 Reporter:  Kbleser  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset OR  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:8 René Fleschenberg]:
 > I understand that this is probably not easy (maybe not possible) for the
 ORM to solve. Maybe I am wrong here, but I think you would expect {{{qs1 |
 qs2}}} to return the same set of results as {{{set(qs1) | set(qs2)}}}? Not
 sure what to do about it, though.

 For this we'd have to use `UNION` instead of combining filters. Queryset
 from the ticket description is really complicated (from the structure
 point of view) with overlap filters, aggregations, filters on aggregated
 values, etc. My point is that you cannot describe it as `Model.filter(x) |
 Model.filter(y)` as it contains aggregations and filters on them. Docs
 don't precise what would happen when you use the `OR` operator on
 `Model.filter(x1).annotate(aggregation).filter(x2) |
 Model.filter(y1).annotate(aggregation).filter(y2)`. If you want to merge
 results of two independent querysets you should use `.union()`.

-- 
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/01070189783a56cc-0bfc7477-ddba-4be3-a7c7-45a95b6db05e-00%40eu-central-1.amazonses.com.

Re: [Django] #34727: Error in CharField with TextChoices and missing max_length parameter

2023-07-21 Thread Django

#34727: Error in CharField with TextChoices and missing max_length parameter
-+-
 Reporter:  osamahasanone|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  test, sqlite,| Triage Stage:
  CharField, max_length,choices  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I suppose database setup could be split between `CREATE DATABASE` and
 table creation with checks run in between.

-- 
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/010701897838ac75-c494e037-f65c-4f94-94f2-0f6017a33a54-00%40eu-central-1.amazonses.com.

Re: [Django] #34714: Async support for get_object_or_404()/get_list_or_404().

2023-07-21 Thread Django

#34714: Async support for get_object_or_404()/get_list_or_404().
-+-
 Reporter:  patagoniapy  |Owner:  Olivier
 |  Tabone
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Olivier Tabone):

 * needs_better_patch:  1 => 0


Comment:

 PR updated. Please proceed to review / add comment in the PR.

 Regards

-- 
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/010701897827fd1c-0287b175-40d9-4adf-8594-d62c021fafeb-00%40eu-central-1.amazonses.com.

Re: [Django] #34728: OR operator on queryset does not work as expected

2023-07-21 Thread Django

#34728: OR operator on queryset does not work as expected
-+-
 Reporter:  Kbleser  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset OR  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by René Fleschenberg):

 Replying to [comment:7 Mariusz Felisiak]:
 > Docs only describe how the OR operator works by rule. The ORM cannot
 analyze user queries and rewrite them.

 I understand that this is probably not easy (maybe not possible) for the
 ORM to solve. Maybe I am wrong here, but I think you would expect {{{qs1 |
 qs2}}} to return the same set of results as {{{set(qs1) | set(qs2)}}}? Not
 sure what to do about it, though.

-- 
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/010701897822156e-86981eba-63dc-4f64-86eb-363fd362b56d-00%40eu-central-1.amazonses.com.

Re: [Django] #29789: Support nested relations in FilteredRelation's condition

2023-07-21 Thread Django

#29789: Support nested relations in FilteredRelation's condition
-+-
 Reporter:  Thomas Riccardi  |Owner:  Matt
 |  Ferrante
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  FilteredRelation | Triage Stage:  Ready for
  nested relations   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e4a5527d1dc2f8183883931560f3a6dcdef0ab0c" e4a5527d]:
 {{{
 #!CommitTicketReference repository=""
 revision="e4a5527d1dc2f8183883931560f3a6dcdef0ab0c"
 Refs #29789 -- Added more tests for FilteredRelation with condition
 outside of relation name.
 }}}

-- 
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/01070189780c9980-727fa58f-b7e1-422c-afdd-346ebe6e93c3-00%40eu-central-1.amazonses.com.

Re: [Django] #34728: OR operator on queryset does not work as expected

2023-07-21 Thread Django

#34728: OR operator on queryset does not work as expected
-+-
 Reporter:  Kbleser  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset OR  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:4 René Fleschenberg]:
 > Natalia, I disagree. It is not a support request (the reporters problem
 was solved by using a different API), but a possible bug in the ORM.
 Combining two querysets with {{{|}}} where at least one of them is non-
 empty should not result in an empty queryset, IMO. If it can (when?), we
 should probably document this.
 >
 > It also seems to me that the behaviour does not match the note in the
 [https://docs.djangoproject.com/en/4.2/ref/models/querysets/#or docs]
 about equivalency with {{{Q}}} objects?

 Queryset that you
 [https://code.djangoproject.com/ticket/34728?replyto=4#comment:1 proposed]
 is not the same query that user used in a sample project, I'm not sure how
 the ORM could figure it out from:

 {{{
 Recipe.objects.filter(
 Q(ingredients__in=self.ingredients.all()
 ).annotate(
 shared_ingredients=Count("ingredients")
 ).filter(shared_ingredients__gte=4)

 |

 Recipe.objects.filter(
 Q(tags__in=self.tags.all()) & Q(ingredients__in=self.ingredients.all()
 ).annotate(
 shared_ingredients=Count("ingredients")
 ).filter(shared_ingredients__gte=2)
 }}}

 Docs only describe how the OR operator works by rule. The ORM cannot
 analyze user queries and rewrite them.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018977dcd014-ed967f88-7212-4d8d-b462-379bda02f56d-00%40eu-central-1.amazonses.com.

Re: [Django] #34728: OR operator on queryset does not work as expected

2023-07-21 Thread Django

#34728: OR operator on queryset does not work as expected
-+-
 Reporter:  Kbleser  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset OR  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by René Fleschenberg):

 Replying to [comment:5 Mariusz Felisiak]:
 > Replying to [comment:4 René Fleschenberg]:
 > > BTW, on Discord, there has been another report about {{{qs1 | qs2}}}
 and {{{qs2 | qs1}}} not being equivalent, which they should be according
 to the docs. This is probably outside of the scope of this ticket, but I
 thought it's worth mentioning here (maybe we can fix both issues in one
 go).
 >
 > Queries may **not** be the same according to
 [https://docs.djangoproject.com/en/dev/ref/models/querysets/#or docs],
 check out #33319:
 > > ''"| is not a commutative operation, as different (though equivalent)
 queries may be generated."''

 I understand "equivalent" as "they will return the same set of results".
 Is that not what the docs mean 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/0107018977da114b-1b9f18c9-ba35-4cb2-bde2-c24db7dd78ab-00%40eu-central-1.amazonses.com.

Re: [Django] #34728: OR operator on queryset does not work as expected

2023-07-21 Thread Django

#34728: OR operator on queryset does not work as expected
-+-
 Reporter:  Kbleser  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset OR  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:4 René Fleschenberg]:
 > BTW, on Discord, there has been another report about {{{qs1 | qs2}}} and
 {{{qs2 | qs1}}} not being equivalent, which they should be according to
 the docs. This is probably outside of the scope of this ticket, but I
 thought it's worth mentioning here (maybe we can fix both issues in one
 go).

 Queries may **not** be the same according to
 [https://docs.djangoproject.com/en/dev/ref/models/querysets/#or docs],
 check out #33319:
 > ''"| is not a commutative operation, as different (though equivalent)
 queries may be generated."''

-- 
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/0107018977b8a82e-8a37584e-6559-4cf0-9015-3809983998ff-00%40eu-central-1.amazonses.com.

Re: [Django] #34362: FilteredRelation doesn’t support conditional expression

2023-07-21 Thread Django

#34362: FilteredRelation doesn’t support conditional expression
-+-
 Reporter:  zhu  |Owner:  Francesco
 |  Panico
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"afc880571d5f5a16b977070b15014f9583524898" afc8805]:
 {{{
 #!CommitTicketReference repository=""
 revision="afc880571d5f5a16b977070b15014f9583524898"
 Refs #34362 -- Added get_child_with_renamed_prefix() hook.
 }}}

-- 
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/01070189778e5b1b-99d69263-c006-4562-94eb-cb5d11e45250-00%40eu-central-1.amazonses.com.

Re: [Django] #34728: OR operator on queryset does not work as expected

2023-07-21 Thread Django

#34728: OR operator on queryset does not work as expected
-+-
 Reporter:  Kbleser  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset OR  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by René Fleschenberg):

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


Comment:

 Natalia, I disagree. It is not a support request (the reporters problem
 was solved by using a different API), but a possible bug in the ORM.
 Combining two querysets with {{{|}}} where at least one of them is non-
 empty should not result in an empty queryset, IMO. If it can (when?), we
 should probably document this.

 It also seems to me that the behaviour does not match the note in the
 [https://docs.djangoproject.com/en/4.2/ref/models/querysets/#or docs]
 about equivalency with {{{Q}}} objects?

 If we can't agree here on whether this is a bug or not, should we start an
 ML discussion?

 BTW, on Discord, there has been another report about {{{qs1 | qs2}}} and
 {{{qs2 | qs1}}} not being equivalent, which they should be according to
 the docs. This is probably outside of the scope of this ticket, but I
 thought it's worth mentioning here (maybe we can fix both issues in one
 go).

-- 
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/01070189778b0962-25d15038-aabb-4784-b1bc-099fe6bacd57-00%40eu-central-1.amazonses.com.

Re: [Django] #32114: Workaround for subtest issue with parallel test runner

2023-07-21 Thread Django

#32114: Workaround for subtest issue with parallel test runner
-+-
 Reporter:  Jordan Ephron|Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  Test subtest | Triage Stage:  Accepted
  parallel   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * cc: Sarah Boyce (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018977730ddb-03e1fc84-4c49-4e43-b28e-3f045c55b722-00%40eu-central-1.amazonses.com.

Re: [Django] #25762: Optimize numberformat.format

2023-07-21 Thread Django

#25762: Optimize numberformat.format
--+
 Reporter:  Jaap Roes |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  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):

 * cc: Sarah Boyce (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701897772d11e-328c0afa-cc86-4aff-9b6b-ace3f0afbff5-00%40eu-central-1.amazonses.com.

Re: [Django] #25251: Inconsistent availability of data from migrations in TestCases when using --keepdb

2023-07-21 Thread Django

#25251: Inconsistent availability of data from migrations in TestCases when 
using
--keepdb
---+
 Reporter:  David Szotten  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.8
 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):

 * cc: Sarah Boyce (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070189777044c4-8654733a-ad92-434c-a207-1476e7a23720-00%40eu-central-1.amazonses.com.

Re: [Django] #34723: `TypeError` when loading a Django app with incorrect type of `choices`

2023-07-21 Thread Django

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

Comment:

> I believe that the code in `Field.get_choices` could be a little more
robust, so exceptions are not raised on incorrect choices type.

I'm not sure it's worth changing, it's clearly user error that's easy to
notice, understand, and fix. Furthermore, there are other places that
assume `choices` is iterable (e.g. `flatchoices`). Are we going to add
protection to all of them? You can find many such edge cases in Django
source code, when a type is assumed. IMO, we don't need to be
overprotective. Especially since this is already covered by a system
check.

> Ideally we'd let the check framework run and report these issues is a
friendlier manner.

Autoreloader cannot run checks after each change, this would have bad
impact on developers experience. We even added an option to not run checks
even once, check out #32296.

--
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/0107018977126a73-cba45f12-25ea-4c1c-812d-03fdc9178d42-00%40eu-central-1.amazonses.com.

38 matches

Mail list logo