Re: [Django] #35276: Push cache backend checks down to backend classes

[Django]

#35276: Push cache backend checks down to backend classes
--+
 Reporter:  Adam Johnson  |Owner:  Almaz
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  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 Almaz):

 * owner:  nobody => Almaz
 * 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/0107018e17669344-fe6f0562-25e9-43eb-9108-6775eac87913-00%40eu-central-1.amazonses.com.

Re: [Django] #30397: Allow app_label and class to be specified in the name argument for indexes and constraints.

[Django]

#30397: Allow app_label and class to be specified in the name argument for 
indexes
and constraints.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Can
 |  Sarıgöl
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by GitHub ):

 In [changeset:"9e35c8b2e37ab228b169e63a71f7221e4e85f3da" 9e35c8b]:
 {{{#!CommitTicketReference repository=""
 revision="9e35c8b2e37ab228b169e63a71f7221e4e85f3da"
 Refs #30397 -- Optimized interpolation of index and constraint names a
 bit.
 }}}
-- 
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/0107018e1747b46d-6d586e22-0ab2-4ae2-96de-3a8fff275834-00%40eu-central-1.amazonses.com.

Re: [Django] #35276: Push cache backend checks down to backend classes

[Django]

#35276: Push cache backend checks down to backend classes
--+
 Reporter:  Adam Johnson  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (System checks)  |  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
--+
Comment (by Mariusz Felisiak):

 Agreed, we recently did the same thing with constraint check
 (0fb104dda287431f5ab74532e45e8471e22b58c8).
-- 
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/0107018e1744c435-707bf17f-84a0-445e-8e6e-fdbf7d137fd4-00%40eu-central-1.amazonses.com.

Re: [Django] #35276: Push cache backend checks down to backend classes

[Django]

#35276: Push cache backend checks down to backend classes
--+
 Reporter:  Adam Johnson  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (System checks)  |  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 Simon Charette):

 * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e1743e6e4-6e36bde1-1e42-42ac-bce5-d1abf25d81fa-00%40eu-central-1.amazonses.com.

Re: [Django] #35277: Issue with the new "formset:added" event

[Django]

#35277: Issue with the new "formset:added" event
-+-
 Reporter:  meesterguyman|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  5.0
 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):

 * cc: Claude Paroz (added)
 * resolution:   => invalid
 * status:  new => closed

Comment:

 This is an intended change (eabc22f919e6c1774842e628400b87ac56c47bce) that
 it [https://docs.djangoproject.com/en/stable/ref/contrib/admin/javascript
 /#inline-form-events documented] and mentioned in
 [https://docs.djangoproject.com/en/stable/releases/4.1/#miscellaneous
 release notes], so revert is not an option. Also, it's explicitly
 documented that:
 > ''"For the `formset:added` event, `event.target` **is the newly added
 row.**"''
-- 
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/0107018e173f70a7-5504b755-a7d0-45b0-90e8-5ffb9cd9cc23-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
-+
 Reporter:  Johannes Maron   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * resolution:  needsinfo =>
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted
 * status:  closed => new

Comment:

 Bisected to 8a6c0203c4e92908c2b26ba54feba4ce7e76d081.
-- 
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/0107018e15fd6604-d2bd660d-0332-4bef-87b6-76a41807876b-00%40eu-central-1.amazonses.com.

[Django] #35277: Issue with the new "formset:added" event

[Django]

#35277: Issue with the new "formset:added" event
+
   Reporter:  meesterguyman |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |Version:  5.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 We have certain custom widgets that need to be initialized when a new form
 is added to an inline. Previously, this event was triggered by the
 following:
 {{{
 $(document).trigger("formset:added", [row, options.prefix]);
 }}}
 We could then use jQuery's "on" method to add whatever callbacks needed to
 be executed. Most importantly, the "row" that was added could be was
 passed to the callback, making it very easy to do what we needed to that
 particular row. In 5.0, this was eliminated, and we have the following
 code instead:
 {{{
 row.get(0).dispatchEvent(new CustomEvent("formset:added", {
   bubbles: true,
   detail: {
 formsetName: options.prefix
   }
 }));
 }}}
 Not sure what the rational for this change was, but would really
 appreciate if you all could at least include the "row" in the detail
 passed here, or preferably revert to the previous code.

 Source is below:
 
https://github.com/django/django/blob/c4df2a77761a1ae392eb5c4803b5712803d5239f/django/contrib/admin/static/admin/js/inlines.js#L91C24-L91C37
-- 
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/0107018e15f52f1a-908fa1d2-3e0b-4f06-823a-44e716073ac9-00%40eu-central-1.amazonses.com.

[Django] #35276: Push cache backend checks down to backend classes

[Django]

#35276: Push cache backend checks down to backend classes
+
   Reporter:  Adam Johnson  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (System checks)  |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 |
+
 Currently, the three system checks for caches are individual functions
 [https://github.com/django/django/blob/main/django/core/checks/caches.py
 in ​django.core.checks.caches]. But two of them relate only to
 `FileBasedCache`, yet still run regardless of which backends are used.
 This structure causes some issues:

 1. `FileBasedCache` and its dependencies are imported even when not used.
 2. Some waste in `check_cache_location_not_exposed()` when no
 `FileBasedCache` is configured, which resolves some paths before checking
 against caches.
 3. The code structure is a bit messy with repeated loops and
 `isinstance(cache, FileBasedCache)` conditions.

 I propose restructuring these checks to live within the cache backend
 classes in `django.core.cache.backends.*`, adopting the same pattern used
 for model and field checks, admin checks, and staticfiles finders. (And
 template backend checks, as I proposed in #35233.)

 This would mean:

 1. Adding `BaseCache.check()` which just does `return []` for now.
 2. Pushing the existing two checks down to a new `FileBasedCache.check()`
 method.
 3. Dropping the existing code.
 4. Checking tests cover the checks sufficiently and they pass with the new
 structure.
 5. Potentially adding a test to cover a custom cache backend with its own
 check.
-- 
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/0107018e15f27f4b-c1de4b08-05ab-40cb-a663-2867cebc3cd9-00%40eu-central-1.amazonses.com.

Re: [Django] #35270: Optimize Model._meta._property_names

[Django]

#35270: Optimize Model._meta._property_names
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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 Adam Johnson):

 I didn’t fully explain the caching. What I meant by “per-class” is
 per-*any*-class, not per *model class* - that means caching values for all
 the property names in `object` (none), in `models.Model` (just `pk`, at
 current), any mixing classes, and so on. Yes, the caching on `Options`
 means it’s cached per *model class*, but just relying on that caching
 means we don’t get to reuse the work done checking everything defined on
 mixins, `Model`, or `object`.

 `weak_key_cache` implements a pattern I’ve played with before to associate
 extra data with an object without attaching arbitrary attributes, since
 they might clash or affect operations like serialization or repr. django-
 upgrade uses [https://github.com/search?q=repo%3Aadamchainz%2Fdjango-
 upgrade%20weakkeydictionary=code a bunch of WeakKeyDictionary
 instances] to keep fixers modular to their own files.

 It doesn’t make sense to use `@weak_key_cache` without the `__dict__`
 optimization, because it requires one call per class, whilst the old
 `dir()` approach checks attributes defined in the class *and* all
 superclasses.

 I profiled `__dict__` without `@weak_key_cache` though, using this
 implementation:

 {{{
 @cached_property
 def _property_names(self):
 """Return a set of the names of the properties defined on the
 model."""
 names = set()
 for klass in self.model.__mro__:
 names.update(
 {
 name
 for name, value in klass.__dict__.items()
 if isinstance(value, property)
 }
 )
 return frozenset(names)
 }}}

 The result was that the calls took 2ms, keeping most of the savings. That
 said, the project I’m using doesn’t have deep model inheritance or many
 mixins, so we wouldn’t expect the caching to do so much.

 If you’d both prefer this version, sure, we can go for it. Best to keep
 things maintainable for all, and we can always add `@weak_key_cache` or
 similar in the future.
-- 
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/0107018e1583ab72-49172593-b3e5-49a1-8c81-551cb56e8a42-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+--
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Comment (by Johannes Maron):

 Absolutely, here is a draft with a commit that exploits the error:
 https://github.com/django/django/pull/17946

 And that's the error:


 {{{
 - 
 ?   -

 + 
 }}}



 If and yes, a bound field will pass the ID as an attribute here:
 
https://github.com/django/django/blob/c4df2a77761a1ae392eb5c4803b5712803d5239f/django/forms/boundfield.py#L96-L99
-- 
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/0107018e1577e16e-53ea79f6-f646-4839-919a-ef0e066ff31f-00%40eu-central-1.amazonses.com.

Re: [Django] #35275: Constraints validation fails on UniqueConstraint using OpClass

[Django]

#35275: Constraints validation fails on UniqueConstraint using OpClass
-+-
 Reporter:  Mathieu Kniewallner  |Owner:  Mathieu
 |  Kniewallner
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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 Mariusz Felisiak):

 * needs_better_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e154ffd3a-f662749b-9c7d-4912-b113-ad6a58f07abb-00%40eu-central-1.amazonses.com.

Re: [Django] #35275: Constraints validation fails on UniqueConstraint using OpClass

[Django]

#35275: Constraints validation fails on UniqueConstraint using OpClass
-+-
 Reporter:  Mathieu Kniewallner  |Owner:  Mathieu
 |  Kniewallner
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Mathieu Kniewallner):

 * has_patch:  0 => 1
 * owner:  nobody => Mathieu Kniewallner
 * 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/0107018e14da7422-36b6a58e-e7d8-4510-8d6a-78dd7c7a38e8-00%40eu-central-1.amazonses.com.

Re: [Django] #35275: Constraints validation fails on UniqueConstraint using OpClass

[Django]

#35275: Constraints validation fails on UniqueConstraint using OpClass
-+-
 Reporter:  Mathieu Kniewallner  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (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 Mariusz Felisiak):

 * cc: Gagaro (added)
 * stage:  Unreviewed => Accepted

Comment:

 Good catch, thanks for the report. Please prepare a patch via GitHub PR (a
 regression test is required).
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e149ae6c8-dd02cd0d-f90e-45df-889b-f1d673bb4401-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+--
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Unreviewed

-- 
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/0107018e14923ded-a0b42a2f-2c2a-4a1c-8205-5c01b3ae60fe-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+-
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:  needsinfo
 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 Natalia Bidart):

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

Comment:

 Thank you Johanness and Jörg!

 Before accepting, we'd still need a sample project or test case showcasing
 the issue, as I can't reproduce the duplicated ID symptom (I'm using
 latest `main` though). I created a project of my own and defined a model
 with a FileField, then configured its admin so the `AdminFileWidget` is
 used. This is the resulting HTML which looks correct to me (at least it
 does not have duplicated `id`s):

 {{{
 Currently: images/test_X66RiS7.py
 
 
 Clear
 Change:
 
 }}}
-- 
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/0107018e14139d31-53d0e32a-92f9-44fb-bee5-7b314ea64e42-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Almaz):

 * owner:  Almaz => (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/0107018e13d05409-8bfa3cd8-1ea4-4826-99a3-afa826f4dd3f-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  Almaz
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Almaz):

 Is this a relevant problem?

 Because, after some period of exploration, I see that most of the code
 were updated.
-- 
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/0107018e13d01fde-e5781091-fdd5-4c25-ba9e-e47e3df41a05-00%40eu-central-1.amazonses.com.

[Django] #35275: Constraints validation fails on UniqueConstraint using OpClass

[Django]

#35275: Constraints validation fails on UniqueConstraint using OpClass
-+-
   Reporter:  Mathieu|  Owner:  nobody
  Kniewallner|
   Type:  Bug| Status:  new
  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  |
-+-
 Adding a `UniqueConstraint` using PostgreSQL-specific `OpClass` on a model
 breaks constraints validation performed when calling
 `validate_constraints` on a model when using PostgreSQL.

 === Minimal reproducer
 {{{#!python
 from django.contrib.postgres.indexes import OpClass
 from django.db import models
 from django.db.models.functions import Lower


 class Place(models.Model):
 name = models.CharField(max_length=255)

 class Meta:
 app_label = "opclass_issue"
 constraints = [
 models.UniqueConstraint(
 OpClass(Lower("name"), name="text_pattern_ops"),
 name="lower_name_uniq",
 )
 ]


 place = Place(name="Narnia")
 place.validate_constraints()
 }}}

 This leads to the following error:
 {{{
 django.db.utils.ProgrammingError: syntax error at or near
 "text_pattern_ops"
 LINE 1: ...place" WHERE LOWER("opclass_issue_place"."name") text_patte...
 }}}

 Full SQL query that is generated:
 {{{#!sql
 SELECT 1 AS "a" FROM "opclass_issue_place" WHERE
 LOWER("opclass_issue_place"."name") text_pattern_ops = (LOWER('narnia')
 text_pattern_ops) LIMIT 1
 }}}

 Just in case, this happens even though `django.contrib.postgres` is
 correctly installed in `INSTALLED_APPS`, so the issue is not related to
 that.

 I've also created a test and adapted the CI to run it in
 https://github.com/backmarket-oss/django/pull/2/files, which leads to
 https://github.com/backmarket-
 oss/django/actions/runs/8171237603/job/22339033423?pr=2 showing the
 failure.

 === Potential root cause

 `OpClass` wrapper should only make sense when creating the constraint, and
 should not be used when validating the constraint, as this leads to an
 invalid SQL query.

 Looking at the code for the PostgreSQL specific `ExclusionConstraint`, a
 similar conclusion was reached, and `OpClass` is explicitly removed in
 `validate` method:
 
https://github.com/django/django/blob/4426b1a72dc289643e2ae8c190b8dc4b3a39daf7/django/contrib/postgres/constraints.py#L211-L216.

 === Potential fix

 Applying a similar fix as the one above in `UniqueConstraint`, showcased
 in https://github.com/backmarket-oss/django/pull/1/files applied on top of
 the other PR above, leads to https://github.com/backmarket-
 oss/django/actions/runs/8171242801/job/22339050847?pr=1 where the added
 test is now passing.

 If you think that this is the correct fix to apply, or have a lead for
 another fix, I'd be happy to make a proper pull request targeting Django
 repository.
-- 
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/0107018e13ca0979-fa582a9e-c0cb-4892-9842-97c8207da856-00%40eu-central-1.amazonses.com.

Re: [Django] #35030: Make django.contrib.auth decorators work with async functions.

[Django]

#35030: Make django.contrib.auth decorators work with async functions.
--+
 Reporter:  Mike Lissner  |Owner:  Dingning
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:  async, decorator  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Comment (by GitHub ):

 In [changeset:"c4df2a77761a1ae392eb5c4803b5712803d5239f" c4df2a77]:
 {{{#!CommitTicketReference repository=""
 revision="c4df2a77761a1ae392eb5c4803b5712803d5239f"
 Refs #35030 -- Added more tests for @user_passes_test decorator.
 }}}
-- 
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/0107018e13bcb58b-196d7b58-2a51-42e9-8820-b729c2581219-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by herrbenesch):

 * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e13b77d6f-7ba83039-ecd0-4651-bd42-093fae25fecf-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+--
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Comment (by herrbenesch):

 I can second the report and will put the triage to accepted.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e13b74951-24e5e6d9-20a7-40ed-af35-2fe739f9c17a-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+--
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Mariusz Felisiak):

 * cc: Marcelo Galigniana, David Smith (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/0107018e13b02498-e2cb5849-b4c2-4401-b7f8-10ec01de35a3-00%40eu-central-1.amazonses.com.

Re: [Django] #35273: AdminFileWidget renders two elements with the same ID

[Django]

#35273: AdminFileWidget renders two elements with the same ID
+--
 Reporter:  Johannes Maron  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Johannes Maron):

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

Comment:

 Hi Natalia,

 Thanks, I appreciate you taking the time looking into this and welcoming
 me. Hehe, but I am not really new ;) I happened to contribute, among other
 things, the template-based form rendering and autocomplete fields. Thus, I
 would consider myself somewhat familiar with this part of Django.

 The test you are pointing to is insufficient, since it doesn't include all
 arguments what would be passed to a widget by a form.
 You can see that the output HTML doesn't include an ID for the
 `input[type=file]`. Which it would obviously have in an actual form.

 Funnily enough, the test actually outputs invalid HTML too. A `label.for`
 attribute must point to an existing ID, which it doesn't.

 I am happy to provide a test that will fail. The regression was introduced
 in Django 5 and only applies to the admin file input template.

 Cheers,
 Joe
-- 
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/0107018e13ad17aa-1c1f73b0-e0df-4bf4-b0ed-eec8ef40ea25-00%40eu-central-1.amazonses.com.

Re: [Django] #35270: Optimize Model._meta._property_names

[Django]

#35270: Optimize Model._meta._property_names
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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 Keryn Knight):

 * cc: Keryn Knight (added)

Comment:

  Adam, do you happen to know the overall percentage of the "win" each of
 the 2 optimisations does? i.e. is 80% of it the change to use the
 `klass.__dict__` or is 95% of it the `weak_key_cache`, etc?

 Is there a world where we get enough of a benefit from ''just'' `Changing
 the function to use __dict__ directly ` that we don't need the
 `weak_key_cache`?

 I ask because the `weak_key_cache` is the kind of deep magic that **I**
 don't fully understand immediately, and because you mentioned caching on a
 ''per-class basis'' but I'd have ''assumed'' (from my naive understanding
 of these innards) that was already approaching done, by virtue of the
 `cached_property` existing on the `Options` per model? (i.e. `Options` is
 a singleton per class)
-- 
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/0107018e13ab44fb-e2c62859-1b9a-49cb-83b4-1f4d976b4357-00%40eu-central-1.amazonses.com.

Re: [Django] #35021: Debug query capturing on psycopg3 disregards execute wrappers.

[Django]

#35021: Debug query capturing on psycopg3 disregards execute wrappers.
-+-
 Reporter:  Ran Benita   |Owner:  Michail
 Type:   |  Chatzis
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Mariusz Felisiak ):

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

Comment:

 In [changeset:"4426b1a72dc289643e2ae8c190b8dc4b3a39daf7" 4426b1a]:
 {{{#!CommitTicketReference repository=""
 revision="4426b1a72dc289643e2ae8c190b8dc4b3a39daf7"
 Fixed #35021 -- Fixed capturing queries when using client-side parameters
 binding with psycopg 3+.
 }}}
-- 
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/0107018e13789a5e-adbd255b-434b-4be5-bdf9-1c0b31e2889a-00%40eu-central-1.amazonses.com.

Re: [Django] #35021: Debug query capturing on psycopg3 disregards execute wrappers.

[Django]

#35021: Debug query capturing on psycopg3 disregards execute wrappers.
-+-
 Reporter:  Ran Benita   |Owner:  Michail
 Type:   |  Chatzis
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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/0107018e134fd9bf-0e370ae4-ab3b-45b1-b958-722450e4702e-00%40eu-central-1.amazonses.com.

Re: [Django] #35021: Debug query capturing on psycopg3 disregards execute wrappers.

[Django]

#35021: Debug query capturing on psycopg3 disregards execute wrappers.
-+-
 Reporter:  Ran Benita   |Owner:  Michail
 Type:   |  Chatzis
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (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 Michail Chatzis):

 * needs_better_patch:  1 => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e130df0bd-76c329e0-71f3-4ac9-89f4-99ea1d69d15a-00%40eu-central-1.amazonses.com.

Re: [Django] #34277: Add where clause in QuerySet.bulk_create() when update_conflicts=True

[Django]

#34277: Add where clause in QuerySet.bulk_create() when update_conflicts=True
-+-
 Reporter:  Alain Delplanque |Owner:  HAMA
 |  Barhamou
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 HAMA Barhamou):

 * needs_better_patch:  1 => 0

Comment:

 ready for another revision
-- 
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/0107018e12f41d4d-dea79073-f349-431d-82b4-bc009fa9fe44-00%40eu-central-1.amazonses.com.