Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali Toosi|Owner:  Ali Toosi
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  documentation,   | Triage Stage:  Ready for
  from_db, model instance loading|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"8b2a93ee5bec74e0b4d84bd5c6a22c62b157232e" 8b2a93ee]:
 {{{
 #!CommitTicketReference repository=""
 revision="8b2a93ee5bec74e0b4d84bd5c6a22c62b157232e"
 [4.0.x] Fixed #33680 -- Corrected example of customizing model loading in
 docs.

 Backport of faab9e6769b01c18d9e3a31504601452eede6150 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/0107018097d6caed-e1dbd3a9-e27c-459a-89f3-79bd49f8c946-00%40eu-central-1.amazonses.com.

Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali Toosi|Owner:  Ali Toosi
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  documentation,   | Triage Stage:  Ready for
  from_db, model instance loading|  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:"faab9e6769b01c18d9e3a31504601452eede6150" faab9e67]:
 {{{
 #!CommitTicketReference repository=""
 revision="faab9e6769b01c18d9e3a31504601452eede6150"
 Fixed #33680 -- Corrected example of customizing model loading in docs.
 }}}

-- 
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/0107018097d62439-be1e800f-f715-494a-a6a9-6cbdab6a7c00-00%40eu-central-1.amazonses.com.

Re: [Django] #29538: Query Expression in ordering of a related object fails

[Django]

#29538: Query Expression in ordering of a related object fails
-+-
 Reporter:  wilhelmhb|Owner:  Eduardo
 |  Rivas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, related object |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  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/0107018097b56aee-5c4f5819-01f7-4ce3-85e1-e771da93280a-00%40eu-central-1.amazonses.com.

Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali Toosi|Owner:  Ali Toosi
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  documentation,   | Triage Stage:  Ready for
  from_db, model instance loading|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * 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/0107018097af9102-3a2c58a1-9f44-443b-900c-97fd51379e3d-00%40eu-central-1.amazonses.com.

Re: [Django] #33681: Cache OPTIONS are not passed to the Redis client. (was: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult)

[Django]

#33681: Cache OPTIONS are not passed to the Redis client.
-+
 Reporter:  Ben Picolo   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  4.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 Mariusz Felisiak):

 * cc: Nick Pope (added)
 * type:  Cleanup/optimization => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. Agreed, we should pass all options to the Redis
 client. Would you like to prepare a patch? It's probably enough to pass
 the OPTIONS to the underlying client, e.g.

 {{{#!diff
 diff --git a/django/core/cache/backends/redis.py
 b/django/core/cache/backends/redis.py
 index e0d30784ff..51701b77b3 100644
 --- a/django/core/cache/backends/redis.py
 +++ b/django/core/cache/backends/redis.py
 @@ -35,6 +35,7 @@ class RedisCacheClient:
  db=None,
  pool_class=None,
  parser_class=None,
 +**options,
  ):
  import redis

 @@ -58,6 +59,7 @@ class RedisCacheClient:
  parser_class = import_string(parser_class)
  parser_class = parser_class or self._lib.connection.DefaultParser

 +self._options = options
  self._pool_options = {"parser_class": parser_class, "db": db}

  def _get_connection_pool_index(self, write):
 @@ -81,7 +83,7 @@ class RedisCacheClient:
  # cache client can be implemented which might require the key to
 select
  # the server, e.g. sharding.
  pool = self._get_connection_pool(write)
 -return self._client(connection_pool=pool)
 +return self._client(connection_pool=pool, **self._options)

  def add(self, key, value, timeout):
  client = self.get_client(key, write=True)
 }}}

 Marking as a release blocker as this is as a bug in the new feature.

-- 
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/01070180979c5a35-2c99546c-be92-4201-bc22-043c4f88fe71-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: SQL generation bug in `.distinct()` when supplied fields go through multiple many-related tables

[Django]

#33682: SQL generation bug in `.distinct()` when supplied fields go through
multiple many-related tables
-+-
 Reporter:  Robert Leach |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql, distinct,   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 The `QuerySet.distinct` and `order_by` methods
 
[https://docs.djangoproject.com/en/4.0/ref/models/querysets/#django.db.models.query.QuerySet.order_by
 don't resolve references to foreign key the same way] when referenced
 models define a `Meta.ordering`.

 You can get a similar crash with way less code by doing

 {{{#!python
 list(TestSynonym.objects.distinct('compound').order_by('compound'))
 }}}

 As the above actually translates to

 {{{#!python
 list(TestSynonym.objects.distinct('compound').order_by('compound__name'))
 }}}

 Due to `TestCompound.Meta.ordering = ('name',)`

 --

 I would argue that this is ''invalid'' but I'm curious to hear what others
 have to say as the resulting error is definitely cryptic there's possibly
 ways we could do things better.

 Given `DISTINCT ON` usage requires a matching `ORDER BY` I see three
 options

 1. Do nothing, users should learn the gotchas of `Meta.ordering` before
 using it. We've got a precedent against that by making aggregations ignore
 `Meta.ordering` in the recent versions.
 2. Make `distinct('related_with_ordering')` behave like `order_by` with
 regards to ordering expansion to make both APIs coherent given they a
 dependent (resulting clause could match). This will require a deprecation
 period and spreads the arguable bad related ordering expansion pattern to
 another method.
 3. Refuse the temptation to guess and make
 `distinct('related_with_ordering')` error out loudly so at least users are
 not presented this cryptic error. This maintains the arguably confusing
 mismatch between both APIs but we stop the spread of `ordering` expansion.

-- 
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/010701809761d05f-54fbd00f-8188-4a52-8af0-b6693aba8e3b-00%40eu-central-1.amazonses.com.

Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali Toosi|Owner:  Ali Toosi
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  documentation,   | Triage Stage:  Accepted
  from_db, model instance loading|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ali Toosi):

 Replying to [comment:2 Mariusz Felisiak]:
 Thanks, Mariusz. I've updated the PR with your suggestion.

-- 
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/010701809679196e-95e56890-0a94-4626-b710-652bc5acbfa0-00%40eu-central-1.amazonses.com.

Re: [Django] #33683: Document HttpResponseBase and allow import from django.http

[Django]

#33683: Document HttpResponseBase and allow import from django.http
-+-
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  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 Collin Anderson):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/15667

-- 
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/0107018095aed58c-8d793ec9-6911-4c58-9a23-574543ae85e6-00%40eu-central-1.amazonses.com.

[Django] #33683: Document HttpResponseBase and allow import from django.http

[Django]

#33683: Document HttpResponseBase and allow import from django.http
+
   Reporter:  Collin Anderson   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  HTTP handling |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 |
+
 HttpResponseBase shouldn't be used directly for creating responses, but
 it's super useful for type-checking, so I think we should document and
 allow import from django.http.

-- 
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/0107018095ad7f37-f2820be5-54ff-4411-976a-c48eca3689b3-00%40eu-central-1.amazonses.com.

[Django] #33682: SQL generation bug in `.distinct()` when supplied fields go through multiple many-related tables

[Django]

#33682: SQL generation bug in `.distinct()` when supplied fields go through
multiple many-related tables
-+-
   Reporter:  Robert |  Owner:  nobody
  Leach  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  sql, distinct,
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have a rather complex database and an advanced search interface that
 creates complex queries.  It’s been working great for over a year now.

 I recently added a feature to count distinct related table records in the
 joined results. When I added fields to these many-related tables to
 `.distinct()` (and to `.order_by()`), I couldn’t get the test to execute
 without hitting an `InvalidColumnReference` error. And though I’m
 supplying the same expanded fields list to `.order_by()` that I am to
 `.distinct()`, the error claims that `SELECT DISTINCT ON expressions must
 match initial ORDER BY expressions`…

 When I print the SQL, the place where it notes a difference has a weird
 `T8` reference where the model name should be in an `order by` clause.
 The corresponding `distinct` clause has the full table name instead of the
 reference, which is what I suspect is triggering the exception.

 I was able to create a set of toy models and a test that minimally
 reproduces the exception...

 toymodels.py:
 {{{
 from django.db.models import Model, CharField, AutoField, ForeignKey,
 ManyToManyField, CASCADE

 class TestPeak(Model):
 id = AutoField(primary_key=True)
 name = CharField(max_length=10)
 compounds = ManyToManyField(
 to="TestCompound",
 related_name="testpeaks",
 )
 class Meta:
 verbose_name = "testpeak"
 verbose_name_plural = "testpeaks"
 ordering = ["name"]

 class TestCompound(Model):
 id = AutoField(primary_key=True)
 name = CharField(max_length=10)
 class Meta:
 verbose_name = "testcompound"
 verbose_name_plural = "testcompounds"
 ordering = ["name"]

 class TestSynonym(Model):
 name = CharField(max_length=10, primary_key=True)
 compound = ForeignKey(
 TestCompound, related_name="testsynonyms", on_delete=CASCADE
 )
 class Meta:
 verbose_name = "testsynonym"
 verbose_name_plural = "testsynonyms"
 ordering = ["compound", "name"]
 }}}

 test_bug.py:
 {{{
 from DataRepo.tests.tracebase_test_case import TracebaseTestCase
 from DataRepo.models.toymodels import TestPeak, TestCompound, TestSynonym
 from django.db.models import Q

 class DjangoSQLBug(TracebaseTestCase):
 maxDiff = None

 @classmethod
 def setUpTestData(cls):
 TestCompound.objects.create(name="testcpd")
 cpd = TestCompound.objects.get(id__exact=1)
 TestSynonym.objects.create(name="testsyn",compound=cpd)
 TestPeak.objects.create(name="testpk")
 pk = TestPeak.objects.get(id__exact=1)
 pk.compounds.add(cpd)

 def test_mm_om_query(self):
 q_exp = Q(name__iexact="testpk")
 distinct_fields = ['name', 'pk',
 'compounds__testsynonyms__compound', 'compounds__testsynonyms__name',
 'compounds__testsynonyms__pk', 'compounds__name', 'compounds__pk']
 qs =
 
TestPeak.objects.filter(q_exp).order_by(*distinct_fields).distinct(*distinct_fields)
 self.assertEqual(qs.count(), 1)
 }}}

 `python manage.py test` output:
 {{{
 Creating test database for alias 'default'...
 Creating test database for alias 'validation'...
 System check identified no issues (0 silenced).
 E
 ==
 ERROR: test_mm_om_query (DataRepo.tests.sqlbugtest.test_bug.DjangoSQLBug)
 --
 Traceback (most recent call last):
   File "/Users/rleach/PROJECT-
 local/TRACEBASE/tracebase/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.InvalidColumnReference: SELECT DISTINCT ON expressions
 must match initial ORDER BY expressions
 LINE 1: ...peak"."id", "DataRepo_testsynonym"."compound_id", "DataRepo_...
  ^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/Users/rleach/PROJECT-
 local/TRACEBASE/tracebase/DataRepo/tests/sqlbugtest/test_bug.py", line 21,
 in test_mm_om_query
 

Re: [Django] #29538: Query Expression in ordering of a related object fails

[Django]

#29538: Query Expression in ordering of a related object fails
-+-
 Reporter:  wilhelmhb|Owner:  Eduardo
 |  Rivas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, related object |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Eduardo Rivas):

 * owner:  Alexandre Laplante => Eduardo Rivas


-- 
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/010701809520a97b-bac00271-aa72-43ab-8026-8646b1e0aed2-00%40eu-central-1.amazonses.com.

Re: [Django] #29538: Query Expression in ordering of a related object fails

[Django]

#29538: Query Expression in ordering of a related object fails
-+-
 Reporter:  wilhelmhb|Owner:  Alexandre
 |  Laplante
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, related object |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Eduardo Rivas):

 * cc: Eduardo Rivas (added)
 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/15666 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/01070180951fc332-7d2f242e-054c-4be8-89f1-816e0b0b52c4-00%40eu-central-1.amazonses.com.

Re: [Django] #33681: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult

[Django]

#33681: Redis client OPTIONS don't work as documented, which makes setting Redis
timeouts difficult
-+-
 Reporter:  bpicolo  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  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 bpicolo:

Old description:

> Hello! First Django interaction, so please let me know how better I can
> give info here.
>
> I discovered unintentionally that there's no default socket_timeout set
> for Redis cache connections. This is an issue on it's own (unsafe default
> that's a particularly hard issue to track down), but in trying to set
> those timeouts, I hit some tough edges of documentation/usage.
>
> The cache documentation says that the OPTIONS object is passed to the
> third-party connection class for connections backed by third-party
> libraries
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20
> for connections backed by third-party libraries]. This is reaffirmed for
> the redis cache specifically
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
> here].
>
> Right now, though, these OPTIONS are passed to the
> [https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
> first-party RedisCacheClient object], so you can't pass in options
> expected by the redis connection pool [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1283 link]. In that sense,
> RedisCacheClient is being treated as a "first-party" cache according to
> these docs, but it defers directly to the redis library.
>
> One could do a variety of subclassing to make this work, but there's
> quite a few layers of indirection here, so it's hard to identify exactly
> what one should subclass in order to get arguments to the connection
> class appropriately.
>
> (For now, my workaround is take advantage of the from_url behavior where
> the connection class [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1274 pulls arguments out of the
> connection query string], but this isn't straightforward and feels
> brittle to django implementation details).
>
> There are a couple of options here – revising documentation or changing
> behavior (or both).
>
> In my ideal case, it would be great for it to be easy to pass down
> explicit socket and other timeouts. To me, that suggests updating
> behavior is ideal, because the documentation would potentially lead folk
> down a path of tough to navigate behavior.

New description:

 Hello! First Django interaction, so please let me know how better I can
 give info here.

 I discovered unintentionally that there's no default socket_timeout set
 for Redis cache connections. This is an issue on it's own (unsafe default
 that's a particularly hard issue to track down), but in trying to set
 those timeouts, I hit some tough edges of documentation/usage.

 The cache documentation says that the OPTIONS object is passed to the
 third-party connection class for connections backed by third-party
 libraries
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20
 for connections backed by third-party libraries]. This is reaffirmed for
 the redis cache specifically
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
 here].

 Right now, though, these OPTIONS are passed to the
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
 first-party RedisCacheClient object], so you can't pass in options
 expected by the redis connection pool [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1283 link]. In that sense,
 RedisCacheClient is being treated as a "first-party" cache according to
 these docs, but it defers directly to the redis 

Re: [Django] #33681: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult

[Django]

#33681: Redis client OPTIONS don't work as documented, which makes setting Redis
timeouts difficult
-+-
 Reporter:  bpicolo  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  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 bpicolo:

Old description:

> Hello! First Django interaction, so please let me know how better I can
> give info here.
>
> I discovered unintentionally that there's no default socket_timeout set
> for Redis cache connections. This is an issue on it's own (unsafe default
> that's a particularly hard issue to track down), but in trying to set
> those timeouts, I hit some tough edges of documentation/usage.
>
> The cache documentation says that the OPTIONS object is passed to the
> third-party connection class for connections backed by third-party
> libraries
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20
> for connections backed by third-party libraries]. This is reaffirmed for
> the redis cache specifically
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
> here].
>
> Right now, though, these OPTIONS are passed to the
> [https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
> first-party RedisCacheClient object], so you can't pass in options
> expected by the redis connection pool [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1283 link]. In that sense,
> RedisCacheClient is being treated as a "first-party" cache according to
> these docs, but it defers directly to the redis library.
>
> One could do a variety of subclassing to make this work, but there's
> quite a few layers of indirection here, so it's hard to identify exactly
> what one should subclass in order to get arguments to the connection
> class appropriately.
>
> (For now, my workaround is take advantage of the from_url behavior where
> the connection class [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1274 pulls arguments out of the
> connection query string], but this isn't straightforward and feels
> brittle).
>
> There are a couple of options here – revising documentation or changing
> behavior (or both).
>
> In my ideal case, it would be great for it to be easy to pass down
> explicit socket and other timeouts. To me, that suggests updating
> behavior is ideal, because the documentation would potentially lead folk
> down a path of tough to navigate behavior.

New description:

 Hello! First Django interaction, so please let me know how better I can
 give info here.

 I discovered unintentionally that there's no default socket_timeout set
 for Redis cache connections. This is an issue on it's own (unsafe default
 that's a particularly hard issue to track down), but in trying to set
 those timeouts, I hit some tough edges of documentation/usage.

 The cache documentation says that the OPTIONS object is passed to the
 third-party connection class for connections backed by third-party
 libraries
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20
 for connections backed by third-party libraries]. This is reaffirmed for
 the redis cache specifically
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
 here].

 Right now, though, these OPTIONS are passed to the
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
 first-party RedisCacheClient object], so you can't pass in options
 expected by the redis connection pool [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1283 link]. In that sense,
 RedisCacheClient is being treated as a "first-party" cache according to
 these docs, but it defers directly to the redis library.

 One could do a variety of 

Re: [Django] #33681: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult

[Django]

#33681: Redis client OPTIONS don't work as documented, which makes setting Redis
timeouts difficult
-+-
 Reporter:  bpicolo  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  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 bpicolo:

Old description:

> Hello! First Django interaction, so please let me know how better I can
> give info here.
>
> I discovered unintentionally that there's no default socket_timeout set
> for Redis cache connections. This is an issue on it's own (unsafe default
> that's a particularly hard issue to track down), but in trying to set
> those timeouts, I hit some tough edges of documentation/usage.
>
> The cache documentation says that the OPTIONS object is passed to the
> third-party connection class for connections backed by third-party
> libraries
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20library
> is passed to the underlying library connection object]. This is
> reaffirmed for the redis cache specifically
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
> here].
>
> Right now, though, these OPTIONS are passed to the
> [https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
> first-party RedisCacheClient object], so you can't pass in options
> expected by the redis connection pool [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1283 link]. In that sense,
> RedisCacheClient is being treated as a "first-party" cache according to
> these docs, but it defers directly to the redis library.
>
> One could do a variety of subclassing to make this work, but there's
> quite a few layers of indirection here, so it's hard to identify exactly
> what one should subclass in order to get arguments to the connection
> class appropriately.
>
> (For now, my workaround is take advantage of the from_url behavior where
> the connection class [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1274 pulls arguments out of the
> connection query string], but this isn't straightforward and feels
> brittle).
>
> There are a couple of options here – revising documentation or changing
> behavior (or both).
>
> In my ideal case, it would be great for it to be easy to pass down
> explicit socket and other timeouts. To me, that suggests updating
> behavior is ideal, because the documentation would potentially lead folk
> down a path of tough to navigate behavior.

New description:

 Hello! First Django interaction, so please let me know how better I can
 give info here.

 I discovered unintentionally that there's no default socket_timeout set
 for Redis cache connections. This is an issue on it's own (unsafe default
 that's a particularly hard issue to track down), but in trying to set
 those timeouts, I hit some tough edges of documentation/usage.

 The cache documentation says that the OPTIONS object is passed to the
 third-party connection class for connections backed by third-party
 libraries
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20
 for connections backed by third-party libraries]. This is reaffirmed for
 the redis cache specifically
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
 here].

 Right now, though, these OPTIONS are passed to the
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
 first-party RedisCacheClient object], so you can't pass in options
 expected by the redis connection pool [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1283 link]. In that sense,
 RedisCacheClient is being treated as a "first-party" cache according to
 these docs, but it defers directly to the redis library.

 One could do 

Re: [Django] #33681: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult

[Django]

#33681: Redis client OPTIONS don't work as documented, which makes setting Redis
timeouts difficult
-+-
 Reporter:  bpicolo  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  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 bpicolo:

Old description:

> Hello! First Django interaction, so please let me know how better I can
> give info here.
>
> I discovered unintentionally that there's no default socket_timeout set
> for Redis cache connections. This is an issue on it's own (unsafe default
> that's a particularly hard issue to track down), but in trying to set
> those timeouts, I hit some tough edges of documentation/usage.
>
> The cache documentation says that, for caches backed by third-party
> libraries, the OPTIONS object
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20library
> is passed to the underlying library connection object]. This is
> reaffirmed for the redis cache specifically
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
> here].
>
> Right now, though, these OPTIONS are passed to the
> [https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
> first-party RedisCacheClient object], so you can't pass in options
> expected by the redis connection pool [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1283 link].
>
> One could do a variety of subclassing to make this work, but there's
> quite a few layers of indirection here, so it's hard to identify exactly
> what one should subclass in order to get arguments to the connection
> class appropriately.
>
> (For now, my workaround is take advantage of the from_url behavior where
> the connection class [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1274 pulls arguments out of the
> connection query string], but this isn't straightforward and feels
> brittle).
>
> There are a couple of options here – revising documentation or changing
> behavior (or both).
>
> In my ideal case, it would be great for it to be easy to pass down
> explicit socket and other timeouts. To me, that suggests updating
> behavior is ideal, because the documentation would potentially lead folk
> down a path of tough to navigate behavior.

New description:

 Hello! First Django interaction, so please let me know how better I can
 give info here.

 I discovered unintentionally that there's no default socket_timeout set
 for Redis cache connections. This is an issue on it's own (unsafe default
 that's a particularly hard issue to track down), but in trying to set
 those timeouts, I hit some tough edges of documentation/usage.

 The cache documentation says that the OPTIONS object is passed to the
 third-party connection class for connections backed by third-party
 libraries
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20library
 is passed to the underlying library connection object]. This is reaffirmed
 for the redis cache specifically
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
 here].

 Right now, though, these OPTIONS are passed to the
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
 first-party RedisCacheClient object], so you can't pass in options
 expected by the redis connection pool [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1283 link]. In that sense,
 RedisCacheClient is being treated as a "first-party" cache according to
 these docs, but it defers directly to the redis library.

 One could do a variety of subclassing to make this work, but there's quite
 a few layers of indirection here, so it's hard to identify exactly what
 one should subclass in order to get arguments to 

Re: [Django] #33681: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult

[Django]

#33681: Redis client OPTIONS don't work as documented, which makes setting Redis
timeouts difficult
-+-
 Reporter:  bpicolo  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  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 bpicolo:

Old description:

> Hello! First Django interaction, so please let me know how better I can
> give info here.
>
> I discovered unintentionally that there's no default socket_timeout set
> for Redis cache connections. This is an issue on it's own (unsafe default
> that's a particularly hard issue to track down), but in trying to set
> those timeouts, I hit some tough edges of documentation/usage.
>
> The cache documentation says that, for caches backed by third-party
> libraries, the OPTIONS object
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20library
> is passed to the underlying library connection object]. This is
> reaffirmed for the redis cache specifically
> [https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
> here].
>
> Right now, though, these OPTIONS are passed to the
> [https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
> first-party RedisCacheClient object], so you can't pass in options
> expected by the redis connection pool [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1283 link].
>
> One could do a variety of subclassing to make this work, but there's
> quite a few layers of indirection here, so it's hard to identify exactly
> what one should subclass in order to get objects to the connection class
> appropriately.
>
> (For now, my workaround is take advantage of the from_url behavior where
> the connection class [https://github.com/redis/redis-
> py/blob/master/redis/connection.py#L1274 pulls arguments out of the
> connection query string], but this isn't straightforward and feels
> brittle).
>
> There are a couple of options here – revising documentation or changing
> behavior (or both).
>
> In my ideal case, it would be great for it to be easy to pass down
> explicit socket and other timeouts. To me, that suggests updating
> behavior is ideal, because the documentation would potentially lead folk
> down a path of tough to navigate behavior.

New description:

 Hello! First Django interaction, so please let me know how better I can
 give info here.

 I discovered unintentionally that there's no default socket_timeout set
 for Redis cache connections. This is an issue on it's own (unsafe default
 that's a particularly hard issue to track down), but in trying to set
 those timeouts, I hit some tough edges of documentation/usage.

 The cache documentation says that, for caches backed by third-party
 libraries, the OPTIONS object
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20library
 is passed to the underlying library connection object]. This is reaffirmed
 for the redis cache specifically
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
 here].

 Right now, though, these OPTIONS are passed to the
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
 first-party RedisCacheClient object], so you can't pass in options
 expected by the redis connection pool [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1283 link].

 One could do a variety of subclassing to make this work, but there's quite
 a few layers of indirection here, so it's hard to identify exactly what
 one should subclass in order to get arguments to the connection class
 appropriately.

 (For now, my workaround is take advantage of the from_url behavior where
 the connection class [https://github.com/redis/redis-
 

[Django] #33681: Redis client OPTIONS don't work as documented, which makes setting Redis timeouts difficult

[Django]

#33681: Redis client OPTIONS don't work as documented, which makes setting Redis
timeouts difficult
+
   Reporter:  bpicolo   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Cache system)   |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 |
+
 Hello! First Django interaction, so please let me know how better I can
 give info here.

 I discovered unintentionally that there's no default socket_timeout set
 for Redis cache connections. This is an issue on it's own (unsafe default
 that's a particularly hard issue to track down), but in trying to set
 those timeouts, I hit some tough edges of documentation/usage.

 The cache documentation says that, for caches backed by third-party
 libraries, the OPTIONS object
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=cache%20backends%20backed%20by%20a%20third%2Dparty%20library%20will%20pass%20their%20options%20directly%20to%20the%20underlying%20cache%20library
 is passed to the underlying library connection object]. This is reaffirmed
 for the redis cache specifically
 
[https://docs.djangoproject.com/en/4.0/topics/cache/#:~:text=The%20Memcached%20and%20Redis%20backends%20pass%20the%20contents%20of%20OPTIONS%20as%20keyword%20arguments%20to%20the%20client%20constructors
 here].

 Right now, though, these OPTIONS are passed to the
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/core/cache/backends/redis.py#L30
 first-party RedisCacheClient object], so you can't pass in options
 expected by the redis connection pool [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1283 link].

 One could do a variety of subclassing to make this work, but there's quite
 a few layers of indirection here, so it's hard to identify exactly what
 one should subclass in order to get objects to the connection class
 appropriately.

 (For now, my workaround is take advantage of the from_url behavior where
 the connection class [https://github.com/redis/redis-
 py/blob/master/redis/connection.py#L1274 pulls arguments out of the
 connection query string], but this isn't straightforward and feels
 brittle).

 There are a couple of options here – revising documentation or changing
 behavior (or both).

 In my ideal case, it would be great for it to be easy to pass down
 explicit socket and other timeouts. To me, that suggests updating behavior
 is ideal, because the documentation would potentially lead folk down a
 path of tough to navigate behavior.

-- 
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/0107018094bd9e80-26b1f5de-3a4d-43db-953b-971374317d3c-00%40eu-central-1.amazonses.com.

Re: [Django] #32338: Accessibility issues with Django forms RadioSelect and CheckboxSelectMultiple

[Django]

#32338: Accessibility issues with Django forms RadioSelect and
CheckboxSelectMultiple
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson):

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


Comment:

 Fixed by ec5659382a5f5fc2daf0c87ccc89d0fb07534874 for #32339.

 It may be possible to followup improving the `p`, `table`, and `ul`
 templates but see https://code.djangoproject.com/ticket/32339#comment: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/010701809438015b-e1a84ed1-806a-42af-92d9-c2e41ca672e4-00%40eu-central-1.amazonses.com.

Re: [Django] #32339: Accessibility issues with Django forms as_table, as_ul, as_p rendering helpers

[Django]

#32339: Accessibility issues with Django forms as_table, as_ul, as_p rendering
helpers
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"ec5659382a5f5fc2daf0c87ccc89d0fb07534874" ec565938]:
 {{{
 #!CommitTicketReference repository=""
 revision="ec5659382a5f5fc2daf0c87ccc89d0fb07534874"
 Fixed #32339 -- Added div.html form template.
 }}}

-- 
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/0107018094359d18-88b54d4b-3ae1-4fff-956a-89eda93bb5fa-00%40eu-central-1.amazonses.com.

Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali-Toosi|Owner:  Ali-Toosi
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  documentation,   | Triage Stage:  Accepted
  from_db, model instance loading|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107018093a23b77-ffc15509-82fb-462a-81d9-4a47bec8dff1-00%40eu-central-1.amazonses.com.

Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali Toosi|Owner:  Ali Toosi
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  documentation,   | Triage Stage:
  from_db, model instance loading|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Ali Toosi
 * needs_better_patch:  0 => 1
 * status:  new => assigned


Comment:

 Thanks for the ticket.

 > The easiest fix for this is to update the field_names too so they would
 1. work and 2. show which fields were not loaded from the db at the time.

 I'd keep the previous behavior and rather filter out `DEFERRED` from the
 list of values, e.g.
 {{{#!diff
 diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
 index 3638c6ccff..ec0232673e 100644
 --- a/docs/ref/models/instances.txt
 +++ b/docs/ref/models/instances.txt
 @@ -103,7 +103,9 @@ are loaded from the database::
  instance._state.adding = False
  instance._state.db = db
  # customization to store the original field values on the
 instance
 -instance._loaded_values = dict(zip(field_names, values))
 +instance._loaded_values = dict(
 +zip(field_names, (value for value from values where value is
 not DEFERRED))
 +)
  return instance

  def save(self, *args, **kwargs):
 }}}

-- 
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/0107018093a1e41f-2c14bd0c-8165-42c9-966d-33df2991e6cb-00%40eu-central-1.amazonses.com.

Re: [Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
 Reporter:  Ali-Toosi|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  documentation,   | Triage Stage:
  from_db, model instance loading|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ali-Toosi):

 * has_patch:  0 => 1


Old description:

> The docs provide an example of how the model instance loading can be
> changed and how `_loaded_values` can be saved for future comparison here:
> https://docs.djangoproject.com/en/4.0/ref/models/instances/
>
> In this example, it checks if there are any values not loaded from db
> then add them as DEFERRED values so class instantiation would work
> (`cls(*values)`). However, this would mean `values` list has items now
> that do not map to any `field_names` so when at the end of the function,
> we zip them together and store in `_loaded_values`, the code will fail.
>
> The easiest fix for this is to update the `field_names` too so they would
> 1. work and 2. show which fields were not loaded from the db at the time.

New description:

 The docs provide an example of how the model instance loading can be
 changed and how `_loaded_values` can be saved for future comparison here:
 https://docs.djangoproject.com/en/4.0/ref/models/instances/

 In this example, it checks if there are any values not loaded from db then
 add them as DEFERRED values so class instantiation would work
 (`cls(*values)`). However, this would mean `values` list has items now
 that do not map to any `field_names` so when at the end of the function,
 we zip them together and store in `_loaded_values`, the code will fail.

 The easiest fix for this is to update the `field_names` too so they would
 1. work and 2. show which fields were not loaded from the db at the time.

 I've opened a PR for this here:
 https://github.com/django/django/pull/15664

--

-- 
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/0107018093992c44-f6c6b328-5569-4f5c-8c1b-14de6dc12484-00%40eu-central-1.amazonses.com.

[Django] #33680: Documentation example of customising model instance loading has a bug

[Django]

#33680: Documentation example of customising model instance loading has a bug
-+-
   Reporter:  Ali-Toosi  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  4.0
  Documentation  |   Keywords:  documentation,
   Severity:  Normal |  from_db, model instance loading
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 The docs provide an example of how the model instance loading can be
 changed and how `_loaded_values` can be saved for future comparison here:
 https://docs.djangoproject.com/en/4.0/ref/models/instances/

 In this example, it checks if there are any values not loaded from db then
 add them as DEFERRED values so class instantiation would work
 (`cls(*values)`). However, this would mean `values` list has items now
 that do not map to any `field_names` so when at the end of the function,
 we zip them together and store in `_loaded_values`, the code will fail.

 The easiest fix for this is to update the `field_names` too so they would
 1. work and 2. show which fields were not loaded from the db at the time.

-- 
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/01070180938cfccb-d8070ec6-67b9-432d-a468-5ece5eb0f256-00%40eu-central-1.amazonses.com.

Re: [Django] #22078: views.Feed methods cannot be decorated

[Django]

#22078: views.Feed methods cannot be decorated
-+-
 Reporter:  Germano Gabbianelli  |Owner:  Marcelo
 |  Galigniana
 Type:  Bug  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.6
 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 Marcelo Galigniana):

 * 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/0107018092df8b14-9eb061d1-9252-4e14-a2a3-2445f750-00%40eu-central-1.amazonses.com.