Re: [Django] #33014: ProjectState.__init__() can assume its real_apps argument is a set

[Django]

#33014: ProjectState.__init__() can assume its real_apps argument is a set
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hey Chris.

 I'm a bit ''Meh'' about the suggestion here but I'll accept so you can
 make the PR for review. (If the others like it...)

 > ...part of Django's internal API

 I'm forever amazed what parts of Django folks out there are using. Perhaps
 not this. :)

 Thanks.

-- 
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.e0f4485a7564bd6cfb2f2daea7ad84f6%40djangoproject.com.

Re: [Django] #33016: Cannot override choices error_messages in model

[Django]

#33016: Cannot override choices error_messages in model
-+-
 Reporter:  suneethdev   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 suneethdev):

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


-- 
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/068.9280b844aaf8b3f3efa927d5bebce09e%40djangoproject.com.

Re: [Django] #33016: Cannot override choices error_messages in model

[Django]

#33016: Cannot override choices error_messages in model
-+-
 Reporter:  suneethdev   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by suneethdev):

 Sorry, I have fixed the issue in serializer like this,
 extra_kwargs = {"type": {"error_messages": {"null": "Value cannot be
 null"}}}

-- 
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/068.0318276f971e9e7c943d58dfd5bca9c8%40djangoproject.com.

[Django] #33016: Cannot override choices error_messages in model

[Django]

#33016: Cannot override choices error_messages in model
-+-
   Reporter: |  Owner:  nobody
  suneethdev |
   Type: | Status:  new
  Uncategorized  |
  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 have a model class (from django.db.model) and a char field with choices
 attribute, my form is not created from django form and i am using a
 serializer in the middle of the model and my static HTML form when
 validating my choices field (dropdown) it shows the default validation
 messages only, i couldn't override the error messages. Thanks in advance.

 here is my code

 class CustomUser(BaseModel, AbstractUser):
 type = models.CharField(choices=TYPES, max_length=20,
 default='super_admin',error_messages={"null":'Value is not a
 valid.',"blank":'Value is not a valid.',"invalid_choice":'Value is not a
 valid.'})

 note: Base model inherited from models.Model

-- 
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/053.323f35a2dfb61bcad46343e3e022d858%40djangoproject.com.

Re: [Django] #33015: QuerySet.extra Use Case: filtering on large lists of tuples (was: QuerySet.extra Use Case: use db indexes when filtering on large lists of tuples)

[Django]

#33015: QuerySet.extra Use Case: filtering on large lists of tuples
-+-
 Reporter:  kris-swann   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  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/068.301421a7bdb81966d79b14af69ddde92%40djangoproject.com.

[Django] #33015: QuerySet.extra Use Case: use db indexes when filtering on large lists of tuples

[Django]

#33015: QuerySet.extra Use Case: use db indexes when filtering on large lists of
tuples
-+-
   Reporter:  kris-  |  Owner:  nobody
  swann  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  QuerySet.extra
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 While reading through the documentation for .extra(..) it looked like use
 cases should be logged as a ticket here -- so here is that.

 In an effort to speed up some slow queries that we've been encountering
 I've been looking into taking advantage of db indexes.

 Basically we have run into the same issue as this SO question:
 https://stackoverflow.com/questions/23991090/django-filter-multiple-
 columns-with-a-list-of-tuples

 We are using Postgres as our backing db.

 We have a model that looks like this

 {{{
 class ExampleModel(models.Model):
 val1 = models.TextField()
 val2 = models.TextField()
 # etc...

 class Meta:
 indexes = [
 models.Index(fields=['val1', 'val2'])
 ]
 }}}


 For demonstration purposes, we'll fill it with sample data

 {{{
 sample_data = [
 ExampleModel(val1=str(v1), val2=str(v2))
 for v1 in range(0,1000)
 for v2 in range(0,1000)
 ]
 ExampleModel.objects.bulk_create(sample_data)
 }}}

 Using a or-chained Q object is significantly slower

 Note: In practice this can be a list of any arbitrary combinations, but
 for ease of generation, we'll use an easy to generate list of tuples
 {{{
 items_to_fetch = [
 (i, j)
 for i in range(0,100)
 for j in range(0,100)
 ]
 }}}


 Using an or-chained Q object:
 {{{
 import time
 query = Q()
 for v1, v2 in items_to_fetch:
 query |= Q(val1=v1, val2=v2)
 start = time.perf_counter()
 ExampleModel.objects.filter(query)
 end = time.perf_counter()
 print(f"{end - start} seconds")

 >>> OUTPUT:
 >>> 43.7399711269 seconds
 }}}

 VS.

 Using .extra(...)
 {{{
 import time
 start = time.perf_counter()
 ExampleModel.objects.extra(
 where=["(val1, val2) in %s"],
 params=[tuple(items_to_fetch)]
 )
 end = time.perf_counter()
 print(f"{end - start} seconds")

 >>> OUTPUT:
 >>> 0.000421895449695 seconds
 }}}



 If there are any alternatives worth trying out, that would be really
 helpful info. I wasn't able to find anything in the docs (although I might
 have just been looking in the wrong places too).

-- 
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/053.c10780c7e581f6f9f1af286899bb91dc%40djangoproject.com.

[Django] #33014: ProjectState.__init__() can assume its real_apps argument is a set

[Django]

#33014: ProjectState.__init__() can assume its real_apps argument is a set
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 [https://github.com/django/django/pull/14760 PR #14760] made all calls to
 `ProjectState.__init__()` pass `real_apps` as a set. In
 
[https://github.com/django/django/blob/54a30a7a00fea6c5e3702282ade6e0238e06de3b/django/db/migrations/state.py#L95
 ProjectState.__init__()] now, then, instead of checking that `real_apps`
 is a set and converting it to a set if not, it can just `assert` that it's
 a set when non-`None`. (Presumably the construction of new `ProjectState`
 objects is part of Django's internal API.) I had made this comment on the
 PR, but it wasn't important enough to hold up the PR because another PR
 was depending on it getting merged.

-- 
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.37a0e5f41b45a2c003031a9daf15a16e%40djangoproject.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  Michael
 |  Schmidt
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aron Podrigal):

 * cc: Aron Podrigal (removed)


-- 
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.eab1913d3dc9eca748da124bf6c2aec9%40djangoproject.com.

Re: [Django] #28401: Allow hashlib.md5() calls to work with FIPS kernels

[Django]

#28401: Allow hashlib.md5() calls to work with FIPS kernels
-+-
 Reporter:  Andrew DiPrinzio |Owner:  Ade Lee
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  FIPS, md5,   | Triage Stage:
  python3.9  |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ade Lee):

 * has_patch:  0 => 1


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

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

Re: [Django] #7018: Make ModelForm multiple inheritance possible

[Django]

#7018: Make ModelForm multiple inheritance possible
-+
 Reporter:  bear330  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  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 Mike Fogel):

 * cc: Mike Fogel (removed)


-- 
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.a3aa2479a39d2dc227af11ad8d2dcc2e%40djangoproject.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  Michael
 |  Schmidt
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mike Fogel):

 * cc: Mike Fogel (removed)


-- 
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.20b129ce963e3ffa136fc962ed5f86f2%40djangoproject.com.

Re: [Django] #28401: Allow hashlib.md5() calls to work with FIPS kernels

[Django]

#28401: Allow hashlib.md5() calls to work with FIPS kernels
-+-
 Reporter:  Andrew DiPrinzio |Owner:  Ade Lee
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  FIPS, md5,   | Triage Stage:
  python3.9  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ade Lee):

 I have added the following pull request to resolve this issue.  Thanks!

 This will allow django to run in fips enabled kernels.  Eventually, when
 support for this
 attribute is available everywhere, we can remove the wrapper function and
 just use what
 is in hashlib.

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

-- 
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.3ba0df9107aba65569ee969334e48946%40djangoproject.com.

Re: [Django] #28401: Allow hashlib.md5() calls to work with FIPS kernels

[Django]

#28401: Allow hashlib.md5() calls to work with FIPS kernels
-+-
 Reporter:  Andrew DiPrinzio |Owner:  Ade Lee
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  FIPS, md5,   | Triage Stage:
  python3.9  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ade Lee):

 * owner:  nobody => Ade Lee
 * 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/064.9d140a2840f76f7ad2dc99b34f26891d%40djangoproject.com.

Re: [Django] #33008: Document prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: Document prefetch_related for GenericForeignKey - Object doesn't exist
behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Looks like the fetching of the object is due to the logic in `__get__`
 
https://github.com/django/django/blob/54a30a7a00fea6c5e3702282ade6e0238e06de3b/django/contrib/contenttypes/fields.py#L231-L245.

 Not sure how feasible it would be to change it without breaking backward
 compatiblity though, you'd likely need to avoid passing `default=None` to
 `get_cached_value` and differentiate the sentinel value from `None`.

-- 
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.a12c590c4e2d512779256d605c2563b0%40djangoproject.com.

Re: [Django] #33008: Document prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: Document prefetch_related for GenericForeignKey - Object doesn't exist
behaviour
--+
 Reporter:  Martin Svoboda|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  Documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Martin Svoboda):

 Thank you, your recommendation actually fix the problem. I propose the
 patch https://github.com/django/django/pull/14762

 I found one problem with the solution. prefetch_related sets
 tag.content_object to None, but access to this tag.content_object actually
 cause extra lookup query.

-- 
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.7e28077924f57d81a376fedb3d320426%40djangoproject.com.

Re: [Django] #33011: my_model.manyrelation_set.all() return empty value

[Django]

#33011: my_model.manyrelation_set.all() return empty value
-+-
 Reporter:  Floréal Cabanettes   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  model set querying   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Floréal.

 I can't see how to reproduce this with the info given. (There must be
 something else going on in your project.)

 Django's `model_fields` tests use these models:


 {{{
 class Foo(models.Model):
 a = models.CharField(max_length=10)
 d = models.DecimalField(max_digits=5, decimal_places=3)


 def get_foo():
 return Foo.objects.get(id=1).pk


 class Bar(models.Model):
 b = models.CharField(max_length=10)
 a = models.ForeignKey(Foo, models.CASCADE, default=get_foo,
 related_name='bars')
 }}}

 This is equivalent to yours here I think (in the relevant respects).

 Adding this test passes:

 {{{
 diff --git a/tests/model_fields/test_foreignkey.py
 b/tests/model_fields/test_foreignkey.py
 index 0cd6d62a55..c51b6d978a 100644
 --- a/tests/model_fields/test_foreignkey.py
 +++ b/tests/model_fields/test_foreignkey.py
 @@ -12,6 +12,14 @@ from .models import Bar, FkToChar, Foo,
 PrimaryKeyCharModel

  class ForeignKeyTests(TestCase):

 +def test_reverse_relation(self):
 +a = Foo.objects.create(id=1, a='abc', d=Decimal('12.34'))
 +# Bar FK defaults to Foo with id=1
 +b = Bar.objects.create(b='bcd')
 +c = Bar.objects.create(b='bcd')
 +d = Bar.objects.create(b='bcd')
 +self.assertSequenceEqual(a.bars.all(), [b, c, d])
 +
  def test_callable_default(self):
  """A lazy callable may be used for ForeignKey.default."""
  a = Foo.objects.create(id=1, a='abc', d=Decimal('12.34'))
 }}}

 This is already covered elsewhere in the test suite (many times).

 Can I ask you to provide a minimal reproduce of your issue?
 Thanks.

-- 
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/068.b644dbf75ccf8d3dc405d817533989c0%40djangoproject.com.

Re: [Django] #32998: process_view() is not called on 404

[Django]

#32998: process_view() is not called on 404
---+--
 Reporter:  jooadam|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by jooadam):

 Replying to [comment:3 Carlton Gibson]:
 > process_view() is run after the URL is resolved. (That's how the view
 `callback` parameter is populated.) So, if resolution raises a 404,
 process_view() will not be called. This is expected AFAICS.

 I would definitely not expect this, or for that matter, to reference the
 other issue I opened, that errors in a 404 not get logged. Django calls
 error handlers views, so I would expect them to work the same way as
 ordinary views, or call them something else. Or the very least, document
 that they are exceptional.

-- 
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.0f56ceb84072f6c9a7fed9d6542f6f14%40djangoproject.com.

Re: [Django] #33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig" discovery

[Django]

#33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig"
discovery
---+--
 Reporter:  Joseph Wayodi  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 I'm going to assume this works. If not, please provide a minimal reproduce
 and we can reopen. Thanks!

-- 
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.f91e2896e7030845eacb52c061db4b53%40djangoproject.com.

Re: [Django] #33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig" discovery

[Django]

#33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig"
discovery
---+--
 Reporter:  Joseph Wayodi  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Does setting the new `AppConfig.default` to `False` not solve this?

 
https://docs.djangoproject.com/en/3.2/ref/applications/#django.apps.AppConfig.default

 See also the [https://docs.djangoproject.com/en/3.2/ref/applications
 /#configuring-applications-ref Configuring Applications] 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/065.b710e1500ab1632a328b08727266ba15%40djangoproject.com.

Re: [Django] #32998: process_view() is not called on 404

[Django]

#32998: process_view() is not called on 404
---+--
 Reporter:  jooadam|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 process_view() is run after the URL is resolved. (That's how the view
 `callback` parameter is populated.) So, if resolution raises a 404,
 process_view() will not be called. This is expected AFAICS.

-- 
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.a93cd3842c19bad3de4dfca7aeee0ca4%40djangoproject.com.

Re: [Django] #32998: process_view() is not called on 404

[Django]

#32998: process_view() is not called on 404
---+--
 Reporter:  jooadam|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  3.2
 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 jooadam):

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


Comment:

 See the attachment.

-- 
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.4a2a3305ba4e9ef7fdde5cb990ed1439%40djangoproject.com.

Re: [Django] #32998: process_view() is not called on 404

[Django]

#32998: process_view() is not called on 404
---+--
 Reporter:  jooadam|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  3.2
 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 jooadam):

 * Attachment "process_view-error.zip" added.


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

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

Re: [Django] #33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig" discovery

[Django]

#33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig"
discovery
--+--
 Reporter:  jwayodi   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  3.2
 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 Samir Shah):

 * cc: Samir Shah (added)


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

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

Re: [Django] #33011: my_model.manyrelation_set.all() return empty value

[Django]

#33011: my_model.manyrelation_set.all() return empty value
-+-
 Reporter:  Floréal Cabanettes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model set querying   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Floréal Cabanettes):

 This apply some filters on the data (like filters given in input).

 But it's not linked to this problem. I try to replace this line by:

 {{{
 my_run = self.queryset.get(pk=pk)
 }}}

 or by :

 {{{
 my_run = Run.objects.get(pk=pk)
 }}}

 and the problem is still the same.

 Replying to [comment:3 Carlton Gibson]:
 > Hi Floréal — thanks for the further detail.
 >
 > Can you give some indication of the prefetch usage in the
 `get_queryset()` method here please:
 >
 > {{{
 > my_run = self.get_queryset().get(pk=pk)
 > }}}
 >
 >
 > Thanks.

-- 
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/068.9032286b7df75b37ff9d4be60cfc1967%40djangoproject.com.

[Django] #33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig" discovery

[Django]

#33013: "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig"
discovery
+
   Reporter:  jwayodi   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (Other)  |Version:  3.2
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 We are in the process of adding support for Django 3.2 to
 [https://github.com/django-oscar/django-oscar Oscar].

 Oscar [https://github.com/django-oscar/django-
 
oscar/blob/04dd391c900537a61dbb0ae5250ca5c2df6bbc4b/src/oscar/core/application.py#L139
 mixes in] its apps' configurations into Django's `AppConfig` class, and
 developers using Oscar then subclass these, to make their own
 modifications:
 {{{
 # my_app/apps.py
 from oscar.core.application import OscarConfig
 class MyAppConfig(OscarConfig):
 # my app modifications
 }}}

 With Django 3.2, for apps added to `INSTALLED_APPS` using the dotted
 Python path to the app package, Django finds all `AppConfig` subclasses in
 the `apps.py` (using
 
[https://github.com/django/django/commit/3f2821af6bc48fa8e7970c1ce27bc54c3172545e
 #diff-
 0f8bc657bc27c9f80385c4814c2c2ebc033bda3e03285a7212965309a481cc70R110-R120
 Python's] `inspect.getmembers`), including ones imported to be subclassed.
 `django.apps.config.AppConfig` itself does get excluded, but this is not
 sufficient, as we and the developers using Oscar do a lot of sub classing
 of these classes.

 To solve this, we would have have to do:
 {{{
 # my_app/apps.py
 from oscar.core import application
 class MyAppConfig(application.OscarConfig):
 # my app modifications
 }}}
 And then ask the developers using Oscar to also do the same.

 The problem with this is:
 - it is not intuitive - Python developers would not typically expect
 imports to cause side effects like this, which creates the potential for
 confusing and hard-to-debug issues
 - it is flaky - a new developer may innocently refactor imports not
 realising why they were done that way, and then encounter the confusing
 issues
 - explicit class imports are normally preferred in Python, unless they
 cause local name clashes, so requiring them for this reason is a bit odd
 - Django itself
 
[https://github.com/django/django/commit/3f2821af6bc48fa8e7970c1ce27bc54c3172545e
 #diff-
 0f8bc657bc27c9f80385c4814c2c2ebc033bda3e03285a7212965309a481cc70R110-R120
 does a check] to exclude `django.apps.config.AppConfig` from being
 detected, which is indicative of the fundamental issue which remains

 It would be nice if Django could mitigate this by having a mechanism for
 deciding which classes are considered (e.g. using something like the
 `abstract` metadata option used for models). In the short term,
 restricting the scanning for `AppConfig` subclasses to those named in the
 `app.py`'s `__all__` variable, if it has one (by e.g.
 
[https://github.com/django/django/commit/3f2821af6bc48fa8e7970c1ce27bc54c3172545e
 #diff-
 0f8bc657bc27c9f80385c4814c2c2ebc033bda3e03285a7212965309a481cc70R110-R120
 adding the filter] `(not hasattr(mod, "__all__") or candidate.__name__ in
 mod.__all__)`), would work, and is a bit more intuitive.

-- 
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.495b7bf4403fd0579ea5ed412f63e575%40djangoproject.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  Michael
 |  Schmidt
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Thomas van Gulick):

 * cc: Thomas van Gulick (removed)


-- 
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.86e424e78fcea05a4f14becdf30d8036%40djangoproject.com.

Re: [Django] #33011: my_model.manyrelation_set.all() return empty value

[Django]

#33011: my_model.manyrelation_set.all() return empty value
-+-
 Reporter:  Floréal Cabanettes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model set querying   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Floréal — thanks for the further detail.

 Can you give some indication of the prefetch usage in the `get_queryset()`
 method here please:

 {{{
 my_run = self.get_queryset().get(pk=pk)
 }}}


 Thanks.

-- 
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/068.be7926ab623f6dfafde305deefb18dbb%40djangoproject.com.

Re: [Django] #33011: my_model.manyrelation_set.all() return empty value

[Django]

#33011: my_model.manyrelation_set.all() return empty value
-+-
 Reporter:  Floréal Cabanettes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model set querying   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Floréal Cabanettes):

 Hi,

 I found the commit responsible for this bug:

 {{{
 036f160733 ("Refs #20577 -- Deferred filtering of prefetched related
 querysets by reverse m2o relation.", 2020-10-06)
 }}}


 The line which cause the problem is on the file
 django/db/models/fields/related_descriptors.py, line 584 (581 at the
 commit, 584 on tag 3.2.6) :

 {{{
 queryset._defer_next_filter = True
 }}}

 If I comment this line, the bug disappear.

 My code is not public (is for my enterprise, not my choice). I try to
 describe a similar architecture bellow:

 I have 2 models, one is "Run", the other "Experiment", related by a
 OneToMany relationship:

 {{{
 class Run(model.Model):
 label = models.CharField(max_length=100, null=False, blank=False)
 owner = models.ForeignKey(User, null=True, blank=True,
 on_delete=models.PROTECT, related_name="run_owner")


 class Experiment(model.Model):
 run = models.ForeignKey(Run, null=False, on_delete=models.PROTECT)
 index1 = models.ForeignKey(Index, null=False,
 on_delete=models.PROTECT, related_name="index1")
 index2 = models.ForeignKey(Index, null=True, blank=True,
 on_delete=models.PROTECT, related_name="index2")
 }}}


 I use the django rest framework to call the server through REST API. For
 one endpoint, I get a run, and I try to get it's experiments, to then make
 a copy of them:

 {{{
 @action(detail=True, methods=["post"])
 def copy(self, request, pk=None):
 try:
 my_run = self.get_queryset().get(pk=pk)
 except ObjectDoesNotExist:
 return Response({"detail": _("Run with id '%s' does not exists") %
 pk},
 status=status.HTTP_404_NOT_FOUND)
 my_experiments = my_run.experiment_set.all()
 for my_experiment in my_experiments:
  my_experiment.pk = None
  ...
  my_experiment.save()
 }}}

 and the problem is that `my_experiments` is empty with django 3.2.6 (and
 no more empty with the line commented like said before).

 I hope this will help to solve the problem...

-- 
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/068.96f63c03361a7a8ff2daa92e339c39c3%40djangoproject.com.

[Django] #33012: Add a Redis cache backend.

[Django]

#33012: Add a Redis cache backend.
-+-
   Reporter:  Carlton|  Owner:  Daniyal Abbasi
  Gibson |
   Type:  New| Status:  assigned
  feature|
  Component:  Core   |Version:  4.0
  (Cache system) |
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Redis is the most used backend for caching. Add a backend into core.

 * [https://www.djangoproject.com/weblog/2020/jul/28/community-survey-2020/
 2020 Django Users Survey]
 * [https://groups.google.com/g/django-developers/search?q=redis Mailing
 list discussions]
 * [https://summerofcode.withgoogle.com/projects/#6292871491092480 2021
 GSoC project]

 [https://github.com/django/django/pull/14437 Pull Request].

-- 
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/056.8ca884b78e4281eaf693d5312a70e526%40djangoproject.com.

Re: [Django] #29898: Adapt schema editors to operate from model states instead of fake rendered models

[Django]

#29898: Adapt schema editors to operate from model states instead of fake 
rendered
models
-+-
 Reporter:  Simon Charette   |Owner:  Manav
 Type:   |  Agarwal
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"54a30a7a00fea6c5e3702282ade6e0238e06de3b" 54a30a7]:
 {{{
 #!CommitTicketReference repository=""
 revision="54a30a7a00fea6c5e3702282ade6e0238e06de3b"
 Refs #29898 -- Changed ProjectState.real_apps to set.
 }}}

-- 
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.ab9af9d7f8fb536bde96cd9f1723502d%40djangoproject.com.