Re: [Django] #35294: Queryset explain can be truncated.

[Django]

#35294: Queryset explain can be truncated.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  explain  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107018e40b0df36-7b55b120-5861-4eba-95c7-3462f159b0ac-00%40eu-central-1.amazonses.com.

Re: [Django] #35302: Property on AppConfig and ModelAdmin for ordering apps and models in admin sidebar

[Django]

#35302: Property on AppConfig and ModelAdmin for ordering apps and models in 
admin
sidebar
-+-
 Reporter:  Michał Pokusa|Owner:  Michał
 |  Pokusa
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin models apps| Triage Stage:
  ordering reorder sidebar move  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Comment:

 Thanks for this ticket, however in #7497 we
 [https://code.djangoproject.com/ticket/25671#comment:11 decided] that in
 most of cases `get_app_list()` is enough to change the default order and
 we're not going to add any new options around that.
-- 
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/0107018e4097b969-3d4fd154-d745-4a7c-919f-2b915c5fc6ed-00%40eu-central-1.amazonses.com.

Re: [Django] #28541: migration introducing a UUID primary key fails on sqlite3

[Django]

#28541: migration introducing a UUID primary key fails on sqlite3
+-
 Reporter:  karyon  |Owner:  bcail
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Mariusz Felisiak ):

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

Comment:

 In [changeset:"593067a8ee43e2167c5ffc92e3cc3c5e40ec4aa4" 593067a]:
 {{{#!CommitTicketReference repository=""
 revision="593067a8ee43e2167c5ffc92e3cc3c5e40ec4aa4"
 Fixed #28541 -- Fixed migrations crash when changing primary key on
 SQLite.
 }}}
-- 
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/0107018e408e9b02-62ae45ff-0030-4914-be0a-41d68d804124-00%40eu-central-1.amazonses.com.

Re: [Django] #35303: Add async implementations to contrib.auth backends

[Django]

#35303: Add async implementations to contrib.auth backends
--+--
 Reporter:  Jon Janzen|Owner:  Jon Janzen
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  5.0
 Severity:  Normal|   Resolution:
 Keywords:  async auth| 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):

 * owner:  nobody => Jon Janzen
 * stage:  Unreviewed => Accepted
 * 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/0107018e408b456d-831363d7-7308-47e7-b56d-d4cc0f1874eb-00%40eu-central-1.amazonses.com.

Re: [Django] #7732: Oracle Backend with SessionPool

[Django]

#7732: Oracle Backend with SessionPool
-+-
 Reporter:  halturin |Owner:  Suraj
 |  Shaw
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  yandex-sprint| Triage Stage:  Accepted
  oracle session pool|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Suraj Shaw):

 * needs_better_patch:  1 => 0
 * needs_tests:  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/0107018e40807269-21a81bc1-dfc0-4c5e-9073-50d16af08664-00%40eu-central-1.amazonses.com.

[Django] #35303: Add async implementations to contrib.auth backends

[Django]

#35303: Add async implementations to contrib.auth backends
+
   Reporter:  Jon Janzen|  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.auth  |Version:  5.0
   Severity:  Normal|   Keywords:  async auth
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In previous tickets (TODO) we've added an async interface to contrib.auth
 and then added async implementations to relevant dependencies in other
 parts of Django.

 The time has come to tie all that work together and provide context-
 switch-free async implementations of auth backends (to the extent possible
 within the current limitations of async django, namely that async ORM
 backends do not exist in main yet)

 More reading here: https://forum.djangoproject.com/t/asyncifying-django-
 contrib-auth-and-signals-and-maybe-sessions/18770

 Quoting from myself in that doc:

   Once the prereqs are done ([see tickets above]), we could asyncify the
 internals of the auth app. This would allow for async-compatible backends
 and then take advantage of them to make the internals of the auth app
 fully async (if called from an async API entrypoint, like the alogin
 function that would be implemented in [above initial ticket]).

   Note that I said async-COMPATIBLE. I envision that subclasses of
 auth.backends.BaseBackend would have several new functions added to
 support async-mode while still supporting sync-mode in the same classes.
 Default implementations of async-mode would be added automatically via
 sync_to_async, and implementers are free to choose to add async support or
 leave the default, slightly inefficient implementation in place.

 You can see a prototype of the implementation on my fork:
 https://github.com/bigfootjon/django/compare/main...bigfootjon:django
 :async-contrib-auth
-- 
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/0107018e400a6b4a-419616cd-feea-4cd6-88a3-92a212c8ec02-00%40eu-central-1.amazonses.com.

[Django] #35302: Property on AppConfig and ModelAdmin for ordering apps and models in admin sidebar

[Django]

#35302: Property on AppConfig and ModelAdmin for ordering apps and models in 
admin
sidebar
-+-
   Reporter:  Michał |  Owner:  Michał Pokusa
  Pokusa |
   Type:  New| Status:  assigned
  feature|
  Component: |Version:  dev
  contrib.admin  |   Keywords:  admin models apps
   Severity:  Normal |  ordering reorder sidebar move
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Currently apps and models registered are sorted only based on "name" that
 comes from `AdminSite._build_app_dict`.

 There is no easy way of reordering models and/or app in the sidebar.
 Solutions found online suggest overriding `AdminSite.get_app_list`, but
 even this approach is not perfect as it uses the `dict` from
 `AdminSite._build_app_dict`, which contains limited information about apps
 and its models. I remember even finding a solution that used JavaScript
 for manual reordering of DOM elements.

 Seems like there are many people, including me, that want to reorder the
 admin sidebar, I assume for more logical placement of models.
 Example where this makes sense is an app with "Question" and "Answer"
 models, where "Answers" will be sorted before "Questions", despite the
 opposite making more sense. Another example is moving main business logic
 apps to the top, where they are easily accessible and moving less often
 used apps to the bottom.

 I propose adding a new property, e.g. "sidebar_order" (`0` by default) or
 something like this, that could be set on `AppConfig` and `ModelAdmin` and
 would have priority when determinining the order in admin sidebar and/or
 model listing when accesing specific app's admin. If it is not provided,
 the standard ordering based on name would take effect. I believe this
 would fit with current similar Django options, like `ordering`,
 `list_display`, custom order of filters etc.

 Example:

 {{{
 @admin.register(Question)
 class QuestionAdmin(admin.ModelAdmin):
 sidebar_order = 1

 ...

 @admin.register(Answer)
 class AnswerAdmin(admin.ModelAdmin):
 sidebar_order = 2

 ...
 }}}

 My proposed solution would be 100% backwards compatible. This change
 requires literally change in 4 lines in `django.contrib.admin.sites` for
 it to work (that is why i mark it as Easy picking), of course more for
 proper implementation.


 Also it would be easy to add ordering to new models without changing the
 ordering of all other models, as one could set the property to values like
 `10`, `20` instead of `1`, `2`, which would allow setting new models
 ordering to any value between e.g. `15`.
-- 
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/0107018e3fe556dd-d307fff5-81db-4f07-a02f-4fb5ea8ac94b-00%40eu-central-1.amazonses.com.

Re: [Django] #28541: migration introducing a UUID primary key fails on sqlite3

[Django]

#28541: migration introducing a UUID primary key fails on sqlite3
+-
 Reporter:  karyon  |Owner:  bcail
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin

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

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

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

[Django]

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

 In [changeset:"8fd953f28abc95aee2e2f59c94d8c58af0d792d7" 8fd953f2]:
 {{{#!CommitTicketReference repository=""
 revision="8fd953f28abc95aee2e2f59c94d8c58af0d792d7"
 [5.0.x] Fixed #35273 -- Fixed rendering AdminFileWidget's attributes.

 Regression in 8a6c0203c4e92908c2b26ba54feba4ce7e76d081.

 Backport of e69019555d683fd6a831f87cb09e3deb86e4e7c7 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/0107018e3e78d34c-864540dc-883c-4df0-85fc-6c67ea314830-00%40eu-central-1.amazonses.com.

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

[Django]

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

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

Comment:

 In [changeset:"e69019555d683fd6a831f87cb09e3deb86e4e7c7" e6901955]:
 {{{#!CommitTicketReference repository=""
 revision="e69019555d683fd6a831f87cb09e3deb86e4e7c7"
 Fixed #35273 -- Fixed rendering AdminFileWidget's attributes.

 Regression in 8a6c0203c4e92908c2b26ba54feba4ce7e76d081.
 }}}
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e3e785a2b-89a89a91-0d6d-4bfc-8b95-29b35214230a-00%40eu-central-1.amazonses.com.

Re: [Django] #34488: ClearableFileInput widget forgets "Clear" selection when form is not valid

[Django]

#34488: ClearableFileInput widget forgets "Clear" selection when form is not 
valid
-+-
 Reporter:  bmihelac |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  4.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin, forms,| Triage Stage:  Ready for
  ClearableFileInput |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak ):

 In [changeset:"3d7235c67b5b0569890411eeba8db2b1e02c89c4" 3d7235c]:
 {{{#!CommitTicketReference repository=""
 revision="3d7235c67b5b0569890411eeba8db2b1e02c89c4"
 Refs #34488 -- Made ClearableFileInput preserve "Clear" checked attribute
 when form is invalid.
 }}}
-- 
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/0107018e3e785a2a-4a218446-996a-43d1-a2ac-77d17ec1698c-00%40eu-central-1.amazonses.com.

Re: [Django] #35289: Chunked transfer encoding is not handled correctly by MultiPartParser

[Django]

#35289: Chunked transfer encoding is not handled correctly by MultiPartParser
-+-
 Reporter:  Kyle Agronick|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  transfer-encoding,   | Triage Stage:
  chunked, multi-part|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * cc: bcail (added)

Comment:

 [https://github.com/django/daphne/issues/476 This Daphne issue] may be
 relevant. There's a quote in that issue (from the ASGI spec) that the ASGI
 server is supposed to dechunk the request - so shouldn't it come to Django
 as a regular (not chunked) request? Hopefully someone else will weigh in
 here as well.

 What ASGI server are you using?
-- 
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/0107018e3e198f52-59d74af4-4b9e-4437-9e7b-481b1d0c54be-00%40eu-central-1.amazonses.com.

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

[Django]

#35276: Push cache backend checks down to backend classes
--+
 Reporter:  Adam Johnson  |Owner:  Almaz
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Comment (by bcail):

 @Almaz, are you still working on this ticket?
-- 
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/0107018e3ddd69ba-ea06b8fd-4af9-470b-af93-491ee1d88d9f-00%40eu-central-1.amazonses.com.

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

[Django]

#35276: Push cache backend checks down to backend classes
--+
 Reporter:  Adam Johnson  |Owner:  Almaz
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by bcail):

 * cc: bcail (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/0107018e3ddce80a-da5cd8ca-5790-4172-b16c-e8bcc0b94135-00%40eu-central-1.amazonses.com.

Re: [Django] #28541: migration introducing a UUID primary key fails on sqlite3

[Django]

#28541: migration introducing a UUID primary key fails on sqlite3
+
 Reporter:  karyon  |Owner:  bcail
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.11
 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 bcail):

 * 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/0107018e3d6051af-115c2b0e-a603-4b0d-9f60-7d5f8d041977-00%40eu-central-1.amazonses.com.

Re: [Django] #35301: Overriding a @property of an abstract model with a GenericRelation causes a models.E025 error.

[Django]

#35301: Overriding a @property of an abstract model with a GenericRelation 
causes a
models.E025 error.
-+-
 Reporter:  Sage Abdullah|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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
-+-
Comment (by Sage Abdullah):

 Thanks both! Here's a much more minimal reproduction that still somewhat
 makes sense.

 {{{
 from django.contrib.contenttypes.fields import GenericForeignKey,
 GenericRelation
 from django.contrib.contenttypes.models import ContentType
 from django.db import models


 class Generic(models.Model):
 content_type = models.ForeignKey(
 ContentType,
 related_name="+",
 on_delete=models.CASCADE,
 )
 object_id = models.CharField(max_length=255)
 content_object = GenericForeignKey()


 class Abstract(models.Model):
 @property
 def generics(self):
 return Generic.objects.filter(
 content_type=ContentType.objects.get_for_model(self),
 object_id=str(self.pk),
 )

 class Meta:
 abstract = True


 class Concrete(Abstract):
 generics = GenericRelation(Generic, related_query_name="concrete")
 }}}
-- 
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/0107018e3d447cde-2e0b9fcb-a17a-4e63-a19c-5e99dabbe0e0-00%40eu-central-1.amazonses.com.

Re: [Django] #35301: Overriding a @property of an abstract model with a GenericRelation causes a models.E025 error.

[Django]

#35301: Overriding a @property of an abstract model with a GenericRelation 
causes a
models.E025 error.
-+-
 Reporter:  Sage Abdullah|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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
-+-
Comment (by Adam Johnson):

 Yeah thanks. I have an idea to fix this by keeping track of seen names
 whilst iterating. Will give it a try tonight.
-- 
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/0107018e3d05a974-e43ebdb5-0616-472f-a6b4-a5622f6e56e6-00%40eu-central-1.amazonses.com.

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

[Django]

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

 * stage:  Accepted => Ready for checkin

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e3d033873-dd4f5445-1db9-4fe8-83dd-f076649bbfb4-00%40eu-central-1.amazonses.com.

Re: [Django] #35301: Overriding a @property of an abstract model with a GenericRelation causes a models.E025 error.

[Django]

#35301: Overriding a @property of an abstract model with a GenericRelation 
causes a
models.E025 error.
-+-
 Reporter:  Sage Abdullah|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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: Adam Johnson (added)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted

Comment:

 Thanks for the detailed report and early testing!
-- 
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/0107018e3cb37fa2-f2716c0d-449d-4153-b552-d45c93b6e864-00%40eu-central-1.amazonses.com.

Re: [Django] #28541: migration introducing a UUID primary key fails on sqlite3

[Django]

#28541: migration introducing a UUID primary key fails on sqlite3
+
 Reporter:  karyon  |Owner:  bcail
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e3cb0d7e4-2e1b171b-4dd4-42c2-8ac2-d0073f199eec-00%40eu-central-1.amazonses.com.

Re: [Django] #35301: Overriding a @property of an abstract model with a GenericRelation causes a models.E025 error. (was: Overriding a @property of an abstract class with a GenericRelation causes a mo

[Django]

#35301: Overriding a @property of an abstract model with a GenericRelation 
causes a
models.E025 error.
-+-
 Reporter:  Sage Abdullah|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sage Abdullah):

 * summary:
 Overriding a @property of an abstract class with a GenericRelation
 causes a models.E025 error.
 =>
 Overriding a @property of an abstract model with a GenericRelation
 causes a models.E025 error.

-- 
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/0107018e3c93a92d-aa3a7ef7-de5a-43a8-bc47-229229e70c76-00%40eu-central-1.amazonses.com.

[Django] #35301: Overriding a @property of an abstract class with a GenericRelation causes a models.E025 error.

[Django]

#35301: Overriding a @property of an abstract class with a GenericRelation 
causes a
models.E025 error.
-+-
   Reporter:  Sage   |  Owner:  nobody
  Abdullah   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 As of faeb92ea13f0c1b2cc83f45b512f2c41cfb4f02d, Django traverses the
 model's MRO to find the names of properties, to later be used in different
 places, such as
 
[https://github.com/django/django/blob/80fe2f439102dc748ff8ddd661d94935915bd3e7/django/db/models/base.py#L1976-L1995
 the check for models.E025]. However, this does not take into account any
 properties that may have been overridden by the final concrete model into
 something else (that's not a `@property`).

 The previous logic only checks for attributes in `dir(self.model)`, so if
 the `@property` has been overridden, it will not trigger the error.

 As an example use case, in Wagtail we have a `Revision` model that uses a
 `GenericForeignKey` to allow saving revisions of any model. For its
 companion, we have an abstract model called `RevisionMixin` that gives you
 methods like `save_revision`, as well as a `revisions` property to query
 the revisions. The default `revisions` property is implemented as a
 `@property` instead of a proper `GenericRelation`, because we need to
 handle the case where the model may use multi-table inheritance (#31269).

 In Wagtail, we handle it by having two content types in the `Revision`
 model: the `base_content_type` (the first non-abstract model) and the
 `content_type` (of the most specific model). In the base `RevisionMixin`
 abstract class, we define a `revisions` `@property` that queries the
 `Revision` model directly using the most basic content type, e.g.
 `Revision.objects.filter(base_content_type=self.get_base_content_type(),
 object_id=str(self.pk))`. This ensures that the `revisions` property
 always returns the correct items, regardless which model (parent vs.
 child) is used for querying.

 For models that don't use multi-table inheritance, we've been suggesting
 developers to override the `revisions` `@property` with a
 `GenericRelation` directly (e.g. `revisions = GenericRelation(...)`). This
 allows them to define the `related_query_name`, without having to use a
 different name for the `GenericRelation` itself (e.g. `_revisions`) and
 without having to override the `revisions` `@property` to return that
 `GenericRelation`.

 Now that I'm aware of the system check, I'm also not sure if it's safe to
 override a `@property` with a `GenericRelation` in a subclass. There might
 be quirks of `@property` that would interfere with how `GenericRelation`
 works, that I didn't know of. But if it's safe, then the error shouldn't
 have been raised.

 It looks like the new Django behaviour might not be intended, as the PR
 and ticket for that commit seem to suggest it was only meant as an
 optimisation.

 If Django would like to keep its new behaviour, I could see a few options
 for us to proceed:
 a) Use `cached_property` instead to bypass the system check (not sure if
 this is a good idea)
 b) Communicate to developers that they should not override the `@property`
 directly with a `GenericRelation`, and should instead define the
 `GenericRelation` with a different name e.g. `_revisions` and override the
 default `@property` to return that `GenericRelation`.

 I have created a simpler reproduction here:
 https://github.com/laymonage/django-e025-repro, with models that use tags
 instead of revisions. It also simulates how we worked around #31269.

 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/0107018e3c933139-5bbdde61-79e2-4fe6-bed4-fbd0812be13f-00%40eu-central-1.amazonses.com.

Re: [Django] #35295: Use INSERT with multiple rows on Oracle 23c+

[Django]

#35295: Use INSERT with multiple rows on Oracle 23c+
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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

Comment:

 In [changeset:"175b04942afaff978013db61495f3b39ea12989b" 175b049]:
 {{{#!CommitTicketReference repository=""
 revision="175b04942afaff978013db61495f3b39ea12989b"
 Fixed #35295 -- Used INSERT with multiple rows on Oracle 23c.
 }}}
-- 
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/0107018e3c71e4f8-6b48eea9-f98b-4b08-8a32-7297aec03ce8-00%40eu-central-1.amazonses.com.

Re: [Django] #35295: Use INSERT with multiple rows on Oracle 23c+

[Django]

#35295: Use INSERT with multiple rows on Oracle 23c+
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak ):

 In [changeset:"912f72a6f057bb39f63d66c7fcf0eab7bf28c7b5" 912f72a]:
 {{{#!CommitTicketReference repository=""
 revision="912f72a6f057bb39f63d66c7fcf0eab7bf28c7b5"
 Refs #35295 -- Added BaseDatabaseOperations.bulk_insert_sql().

 Co-authored-by: Nick Pope 
 }}}
-- 
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/0107018e3c71e4e6-bcb570b0-8162-4871-bdba-1037b1ab03ce-00%40eu-central-1.amazonses.com.

Re: [Django] #15059: Additional Documentation for the objects in the admin templates

[Django]

#15059: Additional Documentation for the objects in the admin templates
-+-
 Reporter:  mlakewood|Owner:  Hassan
 Type:   |  Mian
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  admin templates  | Triage Stage:  Accepted
  override   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Ryan Cheley => Hassan Mian

-- 
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/0107018e3c08a126-387390c6-4252-44a9-aaab-9de1b2190265-00%40eu-central-1.amazonses.com.

Re: [Django] #15059: Additional Documentation for the objects in the admin templates

[Django]

#15059: Additional Documentation for the objects in the admin templates
-+-
 Reporter:  mlakewood|Owner:  Ryan
 Type:   |  Cheley
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  admin templates  | Triage Stage:  Accepted
  override   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * type:  Bug => Cleanup/optimization

-- 
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/0107018e3c07f977-cb00d5ec-3d03-4957-a015-c8acef0bba76-00%40eu-central-1.amazonses.com.

Re: [Django] #35294: Queryset explain can be truncated.

[Django]

#35294: Queryset explain can be truncated.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  explain  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e3bfe3347-e2fc4131-2ecc-4b4d-9786-b4ac8578692a-00%40eu-central-1.amazonses.com.

Re: [Django] #35300: Simple COUNT without OUTER JOIN

[Django]

#35300: Simple COUNT without OUTER JOIN
-+-
 Reporter:  Chrea Chanchhunneng  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Uncategorized|  Version:  4.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  reduce counting  | Triage Stage:
  time,  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Comment:

 Thanks for the ticket, however I'm not sure what do you want to "count"
 and how do you expect to count related objects without `JOIN`s. You could
 probably use `.aggregate(Count(..))` in a subquery but it's hard to tell
 without a concrete example. Please first ask on the
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels (Trac is not one of them) where folks will be eager to
 help.
-- 
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/0107018e3be32a86-516982af-ad4a-4555-877f-733d409dbc67-00%40eu-central-1.amazonses.com.