Re: [Django] #33366: Migration autodetector doesn't handle placeholders in related_name for ForeignKey.

[Django]

#33366: Migration autodetector doesn't handle placeholders in related_name for
ForeignKey.
-+-
 Reporter:  Andrew Chen Wang |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   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


Comment:

 > If we want to address the noop `AlterField` migration being generated
 for all usages of placeholders in related_name there's two way we can do
 that.

 We can leave it as it is. Thanks for describing possible options.

-- 
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/074.32fde71ed590a11ce8f87dbec7bc83ca%40djangoproject.com.

Re: [Django] #27674: Deprecate GeoModelAdmin and OSMGeoAdmin

[Django]

#27674: Deprecate GeoModelAdmin and OSMGeoAdmin
-+-
 Reporter:  Claude Paroz |Owner:  Giannis
 Type:   |  Adamopoulos
  Cleanup/optimization   |   Status:  new
Component:  GIS  |  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 Mariusz Felisiak):

 * has_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/065.cc866e82ede39d7eede51611ff0d423b%40djangoproject.com.

Re: [Django] #33373: Support expressions on rhs for __has_keys, __has_any_keys JSONField lookups. (was: Canont use expression as Right Hand Side of JSONField has_keys lookup)

[Django]

#33373: Support expressions on rhs for __has_keys, __has_any_keys JSONField
lookups.
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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):

 * status:  new => closed
 * type:  Bug => New feature
 * resolution:   => needsinfo


Comment:

 Thanks for this ticket. Only `__has_keys` examples with lists are
 [https://docs.djangoproject.com/en/stable/topics/db/queries/#has-keys
 documented], so it's not a bug but a new feature. I'm skeptical, this can
 be error-prone and tricky to implement for all backends (see
 [https://github.com/django/django/pull/12392#issuecomment-624454015
 discussion]). We can reconsider this decision if someone provides PoC with
 cross-database compatibility.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.45ae5c328838ed8a82df654e8c623c11%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * severity:  Release blocker => Normal
 * cc: Claude Paroz (added)
 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * has_patch:  1 => 0
 * resolution:   => invalid


Comment:

 Replying to [ticket:33372 Nick Pope]:
 > `OSMWidget` and `BaseGeometryWidget` have `.__init__(self, attrs=None)`,
 not `.__init__(self, **kwargs)`, so this is broken.
 >
 > Marking as a release blocker as this is a bug in a new feature
 introduced in 4.0.

 I wouldn't say it's broken, you can set `gis_widget_kwargs = {'attrs':
 {...}}`. Defining widgets with more than `attrs` or a different signature
 is reasonable (e.g. `SplitDateTimeWidget` or `ChoiceWidget`). IMO we
 should leave wide support for all options.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.cf67fae65e1aee89a706bf77ebe13ad9%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:
 |  iGeophysix
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by iGeophysix):

 * owner:  nobody => iGeophysix
 * 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/065.61cbc4abc3f5fea36338091067037386%40djangoproject.com.

Re: [Django] #27674: Deprecate GeoModelAdmin and OSMGeoAdmin

[Django]

#27674: Deprecate GeoModelAdmin and OSMGeoAdmin
-+-
 Reporter:  Claude Paroz |Owner:  Giannis
 Type:   |  Adamopoulos
  Cleanup/optimization   |   Status:  new
Component:  GIS  |  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):

 * status:  closed => new
 * resolution:  fixed =>
 * needs_tests:  1 => 0
 * stage:  Ready for checkin => Accepted


Comment:

 Replying to [comment:10 Nick Pope]:
 > While looking into #33372 I noticed that there are two
 `OpenLayersWidget` classes:
 >
 > - `django.contrib.gis.admin.widgets.OpenLayersWidget` - this is used by
 the deprecated `GeoModelAdmin` class and targets OpenLayers 2.x
 > - `django.contrib.gis.forms.widgets.OpenLayersWidget` - this is used as
 a parent to `OSMWidget` (used by the new `GISModelAdmin`) and targets
 OpenLayers 3.x
 >
 > Deprecation warnings were added for `GeoModelAdmin` and `OSMGeoAdmin` as
 part of this ticket but `.admin.widgets.OpenLayersWidget` has no warning.
 Do we need to add one?

 Agreed, we can deprecate
 `django.contrib.gis.admin.widgets.OpenLayersWidget` in Django 4.1 and
 remove it in 5.0. Let's reopen.

 > Do we also need to warn about `gis/admin/openlayers.html` and
 `gis/admin/osm.html` templates going away? (Not sure whether we add a
 documentation note?)

 As far as I'm concerned, it is not needed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c2710df3904735f1ce661ecf88b7798c%40djangoproject.com.

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

[Django]

#27936: Add some clarifications to "Spanning multi-valued relationships"
-+-
 Reporter:  Thomas Güttler   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Jacob Walls):

 * owner:  nobody => Jacob Walls
 * status:  new => assigned


Comment:

 I linked to this doc in the release note I wrote for #16063. I think the
 main flaw of the doc is it's a bit wordy. It starts with examples, but
 sort of hypothetically, then discusses the implementation, then does
 concrete examples. Could be streamlined. Use the saved space to discuss
 duplicates and joins (that's where I could see the shell session coming
 in). I'll try to give it a 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/065.42d1a9b5b7cf65719301ac721022f7ed%40djangoproject.com.

Re: [Django] #21699: Provide a way to define a model without being registered into the app registry / Get rid of get_registered_model

[Django]

#21699: Provide a way to define a model without being registered into the app
registry / Get rid of get_registered_model
--+-
 Reporter:  Mitar |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:  app-loading   | 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 John Cronan):

 Hi! This is a very old ticket, but I've tested this same approach in 3.2
 and it still works. I'm doing a form-builder type of app, and I decided to
 use dynamic models.

 I get the warning message about "reloading models is not advised as it can
 lead to inconsistencies." In my case, I've ensured that the dynamic models
 don't use any foreign keys (except between each other).

 Considering the scope, "figure out what the registration API becomes":
 just as someone using this capability, I'd suggest that there could be a
 way to suppress the warning when you know that the side effects are not
 harmful. True unregistering, where the side effects with related models
 and such are removed automatically, would be cool but sounds hard.

-- 
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/063.5a6558dbf3d6bd32216e6bc83e02fb66%40djangoproject.com.

[Django] #33373: Canont use expression as Right Hand Side of JSONField has_keys lookup

[Django]

#33373: Canont use expression as Right Hand Side of JSONField has_keys lookup
-+-
   Reporter:  john-  |  Owner:  nobody
  parton |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I expected that the right hand side of the has_keys lookup for JSONField
 could be any expression which returns an array of text, but it appears
 that only python lists of strings are valid.

 I think this is also an issue with 4.0, although I have only tested in on
 3.2

 Consider the following models.

 {{{
 class ProductVariant(models.Model):
 product = models.ForeignKey(
 'catalog.Product', on_delete=models.PROTECT
 )

 attributes = models.JSONField(_("Attributes"), default=dict)

 class Product(models.Model):
 configuration = ArrayField(
 models.TextField()
 )
 }}}


 Attempting to eval the queryset


 {{{
 ProductVariant.objects.filter(attributes__has_keys=F("product__configuration"))
 }}}


 results in


 {{{
 TypeError

 'Col' object is not iterable
 }}}


 As a workaround, here's what I currently do


 {{{
 # Define the custom function
 class HasAllKeys(Func):
 function = None
 template = '(%(expressions)s)'
 arg_joiner = ' ?& '
 arity = 2
 output_field = BooleanField()

 ProductVariant.objects.alias(
 attributes_has_configuration_keys=HasAllKeys("attributes",
 "product__configuration")
 ).filter(
 attributes_has_configuration_keys=True
 )
 }}}

-- 
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/054.87ec57bebd0f7d54a68eb5d0aa159d05%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Nick Pope):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1
 * easy:  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/065.43b27932329fee43d1102ad2af3e2d8d%40djangoproject.com.

Re: [Django] #27674: Deprecate GeoModelAdmin and OSMGeoAdmin

[Django]

#27674: Deprecate GeoModelAdmin and OSMGeoAdmin
-+-
 Reporter:  Claude Paroz |Owner:  Giannis
 Type:   |  Adamopoulos
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 While looking into #33372 I noticed that there are two `OpenLayersWidget`
 classes:

 - `django.contrib.gis.admin.widgets.OpenLayersWidget` - this is used by
 the deprecated `GeoModelAdmin` class and targets OpenLayers 2.x
 - `django.contrib.gis.forms.widgets.OpenLayersWidget` - this is used as a
 parent to `OSMWidget` (used by the new `GISModelAdmin`) and targets
 OpenLayers 3.x

 Deprecation warnings were added for `GeoModelAdmin` and `OSMGeoAdmin` as
 part of this ticket but `.admin.widgets.OpenLayersWidget` has no warning.
 Do we need to add one?

 Do we also need to warn about `gis/admin/openlayers.html` and
 `gis/admin/osm.html` templates going away? (Not sure whether we add a
 documentation note?)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.379fdeea445a1c42c0c481db2f85eeb5%40djangoproject.com.

[Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
   Reporter:  Nick Pope  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  GIS|Version:  4.0
   Severity:  Release|   Keywords:  gismodeladmin,
  blocker|  gis_widget_kwargs
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This issue was raised in https://github.com/django/django/pull/15207.

 The problem is that the `gis_widget_kwargs` attribute of
 `GeoModelAdminMixin` is `**`-unpacked into `gis_widget` which is
 `OSMWidget` by default.

 `OSMWidget` and `BaseGeometryWidget` have `.__init__(self, attrs=None)`,
 not `.__init__(self, **kwargs)`, so this is broken.

 Marking as a release blocker as this is a bug in a new feature introduced
 in 4.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/050.c1051731acb0a1a5f5f132ed23982807%40djangoproject.com.

Re: [Django] #33369: Add through_defaults as argument for m2m_changed signal

[Django]

#33369: Add through_defaults as argument for m2m_changed signal
-+-
 Reporter:  ShmuelTreiger|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  m2m_changed  | 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):

 You can start a discussion on DevelopersMailingList if you don't agree,
 where you'll reach a wider audience and see what other think, and
 [https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
 features/#requesting-features follow the guidelines with regards to
 requesting features].

 Also, please don't use offensive language, and be aware that
 [https://www.djangoproject.com/conduct/ "Code of Conduct"] applies to the
 Trac.

-- 
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/071.be2ec8c64f753de02cb91f9a51915bd7%40djangoproject.com.

Re: [Django] #33366: Migration autodetector doesn't handle placeholders in related_name for ForeignKey.

[Django]

#33366: Migration autodetector doesn't handle placeholders in related_name for
ForeignKey.
-+-
 Reporter:  Andrew Chen Wang |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Simon Charette):

 * needs_better_patch:  1 => 0


Comment:

 Removing the ''patch needs improvement'' flag as I believe the noop
 `AlterField` for the un-interpolated `related_name` is expected and
 documented in the Django 4.0 release notes (see #32676).

 I think the conclusion in comment:6 is wrong as I managed to reproduce the
 ''swappable'' dependency issue without involving `related_name` and the
 noop `AlterField` manifestation on Django 4.0 can be achieved without
 involving ''swappable'' models.

 If we want to address the noop `AlterField` migration being generated for
 all usages of placeholders in `related_name` there's two way we can do
 that.

 1. Augment the documentation to mention under which circumstances such
 `AlterField` operations can be created and mention that it is safe to
 adjust history migrations to use the proper ''placeholder'' syntax to
 prevent it from happeing (it's safe even if your library supports Django <
 4.0 as well because the models were rendered and thus `related_name` were
 evaluated at field binding time).
 2. Adjust the auto-detector to consider `'app_model` and
 `'%(app_label)s_%(class)s'` equals (in the context of a `app.Model` model)
 to prevent changes from being detected. This will have the unfortunate
 side effect to prevent changes of a field from harcoded to placeholders
 based `related_name` to be detected by the framework which could be
 considered a limitation of the previous approach model rendering based
 approach.

 I personally think that 1. is the way to go but I don't have a strong
 feeling 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/074.94d73f81e6f12317de4c9fc53c575244%40djangoproject.com.

Re: [Django] #33369: Add through_defaults as argument for m2m_changed signal

[Django]

#33369: Add through_defaults as argument for m2m_changed signal
-+-
 Reporter:  ShmuelTreiger|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  m2m_changed  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ShmuelTreiger):

 I'm literally doing what your documentation tells me to do, and it's
 shitty, hacky, and horrible. Your response is "Won't fix". Excellent.

-- 
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/071.fbe31ae34d03cac4fb5f75533e7f6891%40djangoproject.com.

Re: [Django] #33369: Add through_defaults as argument for m2m_changed signal

[Django]

#33369: Add through_defaults as argument for m2m_changed signal
-+-
 Reporter:  ShmuelTreiger|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  m2m_changed  | 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:

 Please don't reopen closed ticket. You have a custom intermediate models,
 so in your case `.create()` or `.save()` seem ideal to handle this logic.
 As you already described there are at least two ways for your use case. We
 don't want to add a third way. Moreover, signals are required in really
 rare cases and it's definitely not one of 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/071.9e0d22d58a0adceab41cabe7f79bfe38%40djangoproject.com.

Re: [Django] #33369: Add through_defaults as argument for m2m_changed signal

[Django]

#33369: Add through_defaults as argument for m2m_changed signal
-+-
 Reporter:  ShmuelTreiger|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  m2m_changed  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ShmuelTreiger):

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


Comment:

 `domain.policy_set.add(<>)` does not call save() on the m2m model. From
 the documentation here
 
https://docs.djangoproject.com/en/4.0/ref/models/relations/#django.db.models.fields.related.RelatedManager.add

 >Using add() with a many-to-many relationship, however, will not call any
 save() methods (the bulk argument doesn’t exist), but rather create the
 relationships using QuerySet.bulk_create(). If you need to execute some
 custom logic when a relationship is created, listen to the m2m_changed
 signal, which will trigger pre_add and post_add actions.

 I tried `save`, it didn't work, so I found the documentation which told me
 to use `m2m_changed`.

 I suppose instead of `add`, I could do
 `Domain_Policy_m2m.objects.create(<>)` but that's just seems less than
 ideal.

-- 
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/071.b2b2f314516aa5319d1649ff83973ee7%40djangoproject.com.

Re: [Django] #29294: ModelAdmin.raw_id_fields should be included in select_related() by change_view and used by raw id widget

[Django]

#29294: ModelAdmin.raw_id_fields should be included in select_related() by
change_view and used by raw id widget
-+-
 Reporter:  Yurii Zolot'ko   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.11
 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 Jurrian Tromp):

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


Comment:

 I was about to create a new issue for what I think is the same thing so
 reopening, I  [https://stackoverflow.com/questions/65794839/using-
 prefetch-related-in-django-in-combination-with-raw-id-fields also
 encountered] this problem.

 As stated the label_and_url_for_value() does a get() for each item. When
 using the raw_id_fields, this is something you don't want. Especially
 because it does not work with prefetching. I worked around the bug by
 subclassing it in my own project and actually did a benchmark:

 **Benchmark: change view page with 180 inline items with relations:**
 1. Using no raw_id_field: 1658 queries
 2. With raw_id_field and prefetching in Django 3.1: 384 queries
 3. Patched raw_id_field and prefetching: 18 queries

 This proves that my patched ForeignKeyRawIdWidget considerably reduces
 queries as they already have been prefetched.
 The culprit here is django.contrib.admin.widgets:176
 {{{obj = self.rel.model._default_manager.using(self.db).get(**{key:
 value})}}}

 This is a excerpt of what is needed to improve the behaviour which can be
 backwards compatible: we just need to try if value.pk exists, if not we
 use the default behaviour:

 {{{
 class ForeignKeyRawIdWidget(widgets.ForeignKeyRawIdWidget):
 def format_value(self, value):
 """Try to return the `pk` if value is an object, otherwise just
 return
  the value as fallback."""

 if value == '' or value is None:
 return None

 try:
 return str(value.pk)
 except AttributeError:
 return str(value)

 def label_and_url_for_value(self, value):
 """Instead of the original we do not have do a `get()` anymore
 instead
 access the instance directly so when value is prefetched this will
 prevent additional queries."""

 try:
 pk = value.pk
 meta = value._meta
 except AttributeError:
 # Fallback for compatibility with plain pk values
 return super().label_and_url_for_value(value)
 }}}


 Note that this is what I made in order to fix it in a project. If accepted
 I can provide a more permanent solution. Please let me know if this of
 interest.

-- 
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/064.7cb0872790007e51b432e2e9e102a8d0%40djangoproject.com.

Re: [Django] #33350: never_cache()/cache_control() decorators raise error on duck-typed requests.

[Django]

#33350: never_cache()/cache_control() decorators raise error on duck-typed
requests.
-+-
 Reporter:  Terence Honles   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c1d2e8b9b8f41d3effef03badc78c8b8995a99b6" c1d2e8b]:
 {{{
 #!CommitTicketReference repository=""
 revision="c1d2e8b9b8f41d3effef03badc78c8b8995a99b6"
 [4.0.x] Fixed #33350 -- Reallowed using cache decorators with duck-typed
 HttpRequest.

 Regression in 3fd82a62415e748002435e7bad06b501750c.

 Thanks Terence Honles for the report.
 Backport of 40165eecc40f9e223702a41a0cb0958515bb1f82 from main
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.8d9ad88f35afc699a35432f8ee79d8c5%40djangoproject.com.

Re: [Django] #33350: never_cache()/cache_control() decorators raise error on duck-typed requests.

[Django]

#33350: never_cache()/cache_control() decorators raise error on duck-typed
requests.
-+-
 Reporter:  Terence Honles   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Release blocker  |   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:"40165eecc40f9e223702a41a0cb0958515bb1f82" 40165eec]:
 {{{
 #!CommitTicketReference repository=""
 revision="40165eecc40f9e223702a41a0cb0958515bb1f82"
 Fixed #33350 -- Reallowed using cache decorators with duck-typed
 HttpRequest.

 Regression in 3fd82a62415e748002435e7bad06b501750c.

 Thanks Terence Honles for the report.
 }}}

-- 
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/071.dfa5bfc4b4e1535efd6893dc62097da6%40djangoproject.com.

Re: [Django] #30127: Deprecate cached_property's name argument

[Django]

#30127: Deprecate cached_property's name argument
-+-
 Reporter:  Tim Graham   |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  4.0  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"068b2c072b0d28cbd5ea63811779629cdaad8638" 068b2c07]:
 {{{
 #!CommitTicketReference repository=""
 revision="068b2c072b0d28cbd5ea63811779629cdaad8638"
 Fixed #30127 -- Deprecated name argument of cached_property().
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9e18b0d445f5f0402a155765c2f4e330%40djangoproject.com.

Re: [Django] #30127: Deprecate cached_property's name argument

[Django]

#30127: Deprecate cached_property's name argument
-+-
 Reporter:  Tim Graham   |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  4.0  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/067.2cccf894605bb7b6de9a260a21f4f805%40djangoproject.com.

Re: [Django] #33350: never_cache()/cache_control() decorators raise error on duck-typed requests.

[Django]

#33350: never_cache()/cache_control() decorators raise error on duck-typed
requests.
-+-
 Reporter:  Terence Honles   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.0
 Severity:  Release blocker  |   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 Carlton Gibson):

 * 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/071.15a58fa1ea8b500ca1c1e3e1c415f279%40djangoproject.com.

Re: [Django] #31583: Extend deferred unique constraint support to OneToOneField

[Django]

#31583: Extend deferred unique constraint support to OneToOneField
-+-
 Reporter:  BorisZZZ |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  DEFERRED | 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 Petr Přikryl):

 I think it would be quite easy. Here we could pass `deferrable` argument
 based on `new_field.defer` value:

 
https://github.com/django/django/blob/4.0/django/db/backends/base/schema.py#L810
 
https://github.com/django/django/blob/4.0/django/db/backends/base/schema.py#L1245

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.31b0e8f19e99ecfb3f5c82cfaa6c9991%40djangoproject.com.

Re: [Django] #33371: Unnecessary colon with blank label

[Django]

#33371: Unnecessary colon with blank label
---+--
 Reporter:  Timur Kadyev   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  4.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):

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


Comment:

 Thanks for the report, however I don't see any extra colon when rendering
 a form. Can you be more precise? A sample project or reproducible scenario
 would be helpful.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.fced19390aa330af2089fd8233212c43%40djangoproject.com.

Re: [Django] #33371: Unnecessary colon with blank label

[Django]

#33371: Unnecessary colon with blank label
---+--
 Reporter:  Timur Kadyev   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Timur Kadyev:

Old description:

> class AForm(forms.ModelForm):
>
> class Meta:
> labels = {'field_name': ''}
>
> If tag = "", then an unnecessary colon is left
>
> This is, of course, a trifle. But anyway...

New description:

 {{{
 class AForm(forms.ModelForm):

 class Meta:
 labels = {'field_name': ''}
 }}}


 If tag = "", then an unnecessary colon is left

 This is, of course, a trifle. But anyway...

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b02f27fd87b280660c0c55b1638b29c1%40djangoproject.com.

[Django] #33371: Unnecessary colon with blank label

[Django]

#33371: Unnecessary colon with blank label
-+
   Reporter:  Timur Kadyev   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |Version:  4.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  |
-+
 class AForm(forms.ModelForm):

 class Meta:
 labels = {'field_name': ''}

 If tag = "", then an unnecessary colon is left

 This is, of course, a trifle. But anyway...

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.4f8e80b2fc408ad41174630eaabb1736%40djangoproject.com.

Re: [Django] #33350: never_cache()/cache_control() decorators raise error on duck-typed requests.

[Django]

#33350: never_cache()/cache_control() decorators raise error on duck-typed
requests.
-+-
 Reporter:  Terence Honles   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.0
 Severity:  Release blocker  |   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):

 * owner:  Terence Honles => Mariusz Felisiak
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15206 PR]

-- 
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/071.0eda641f706e2d1ff530c8b7e2601d60%40djangoproject.com.