Re: [Django] #34136: Django 4.1.3 doesn't work with psycopg2 2.9.5 with Python 3.11.0

[Django]

#34136: Django 4.1.3 doesn't work with psycopg2 2.9.5 with Python 3.11.0
-+-
 Reporter:  אורי |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, however it seems to be an issue in a local
 configuration, `psycopg2`, or Python 3.11, not in Django itself.

-- 
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/010701843c11579f-848d2f20-4120-456b-85f4-22c8734e520f-00%40eu-central-1.amazonses.com.

Re: [Django] #34080: __exact lookup on nested arrays with None values fails on PostgreSQL.

[Django]

#34080: __exact lookup on nested arrays with None values fails on PostgreSQL.
-+-
 Reporter:  Ion Alberdi  |Owner:  Ion
 |  Alberdi
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  4.1
 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):

 * 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/010701843c0d36db-e01d855a-cb20-4514-86cf-55125183a96c-00%40eu-central-1.amazonses.com.

Re: [Django] #34136: Django 4.1.3 doesn't work with psycopg2 2.9.5 with Python 3.11.0

[Django]

#34136: Django 4.1.3 doesn't work with psycopg2 2.9.5 with Python 3.11.0
-+-
 Reporter:  אורי |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (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
-+-
Description changed by אורי:

Old description:

> If I run tests or `makemigrations` with Django 4.1.3 and psycopg2 2.9.5
> on Windows, I get this error message:
>
> {{{
> django.core.exceptions.ImproperlyConfigured: Error loading psycopg2
> module: DLL load failed while importing _psycopg: The specified module
> could not be found.
> }}}

New description:

 If I run tests or `makemigrations` with Django 4.1.3 and psycopg2 2.9.5
 with Python 3.11.0 on Windows, I get this error message:

 {{{
 django.core.exceptions.ImproperlyConfigured: Error loading psycopg2
 module: DLL load failed while importing _psycopg: The specified module
 could not be found.
 }}}

--

-- 
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/010701843bf1750f-2562f58b-9ff2-45c8-b392-0b53137b4d2d-00%40eu-central-1.amazonses.com.

[Django] #34136: Django 4.1.3 doesn't work with psycopg2 2.9.5 with Python 3.11.0

[Django]

#34136: Django 4.1.3 doesn't work with psycopg2 2.9.5 with Python 3.11.0
-+-
   Reporter:  אורי   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  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  |
-+-
 If I run tests or `makemigrations` with Django 4.1.3 and psycopg2 2.9.5 on
 Windows, I get this error message:

 {{{
 django.core.exceptions.ImproperlyConfigured: Error loading psycopg2
 module: DLL load failed while importing _psycopg: The specified module
 could not be found.
 }}}

-- 
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/010701843beee316-8ec67703-5ab8-4fa3-a835-6d92b82ff123-00%40eu-central-1.amazonses.com.

Re: [Django] #31641: Admin Sidebar flashes when page loads

[Django]

#31641: Admin Sidebar flashes when page loads
-+-
 Reporter:  Collin Anderson  |Owner:  Collin
 |  Anderson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 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):

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


Comment:

 Gavin, please open a new 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/010701843be2c4bf-004e6ddd-8752-419a-b338-195b0d347f9c-00%40eu-central-1.amazonses.com.

Re: [Django] #31641: Admin Sidebar flashes when page loads

[Django]

#31641: Admin Sidebar flashes when page loads
-+-
 Reporter:  Collin Anderson  |Owner:  Collin
 |  Anderson
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  3.1
 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 Gavin Wahl):

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


Comment:

 This doesn't fix the bug because the sidebar still renders before the
 script runs, because it has the defer attribute on it. The correct way to
 do this would be to load nav_sidebar.js right after the sidebar html is
 rendered.

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

-- 
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/010701843a780486-68885186-011c-4794-96d1-88a90f4c9437-00%40eu-central-1.amazonses.com.

Re: [Django] #34135: Add async interface to ManyRelatedManager & RelatedManager

[Django]

#34135: Add async interface to ManyRelatedManager & RelatedManager
-+-
 Reporter:  Jon Janzen   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  async| 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 Jon Janzen:

Old description:

> With #34112 and #33646 combined, there is now an async interface for
> reading/writing Models in a lot of cases. One of the obvious places where
> that isn't true is in `RelatedManager` instances. `RelatedManager`
> instances are missing async versions of:
>
> * `add`
> * `remove`
> * `clear`
> * `set`
>
> And this might be a separate ticket but the docs [1] are missing a
> reference to `acreate` which according to `dir()` exists on
> `ManyRelatedManager` (I assume as a consequence of inheriting from some
> superclass `Manager` type) but I didn't actually try and see if it works.
> I'm suspicious that it might not be fully correct as
> `related_descriptors.py` includes a possibly custom version of the
> synchronous `create` function (see [2] & [3]).
>
> [1]
> https://docs.djangoproject.com/en/dev/ref/models/relations/#django.db.models.fields.related.RelatedManager
> [2]
> https://github.com/django/django/blob/main/django/db/models/fields/related_descriptors.py#L788-L792
> [3]
> https://github.com/django/django/blob/main/django/db/models/fields/related_descriptors.py#L1186-L1190

New description:

 With #34112 and #33646 combined, there is now an async interface for
 reading/writing Models in a lot of cases. One of the obvious places where
 that isn't true is in `RelatedManager` instances. `RelatedManager`
 instances are missing async versions of:

 * `add`
 * `remove`
 * `clear`
 * `set`

 And this might be a separate ticket but the docs (1) are missing a
 reference to `acreate` which according to `dir()` exists on
 `ManyRelatedManager` (I assume as a consequence of inheriting from some
 superclass `Manager` type) but I didn't actually try and see if it works.
 I'm suspicious that it might not be fully correct as
 `related_descriptors.py` includes a possibly custom version of the
 synchronous `create` function (see (2) & (3)).

 (1)
 
https://docs.djangoproject.com/en/dev/ref/models/relations/#django.db.models.fields.related.RelatedManager
 (2)
 
https://github.com/django/django/blob/main/django/db/models/fields/related_descriptors.py#L788-L792
 (3)
 
https://github.com/django/django/blob/main/django/db/models/fields/related_descriptors.py#L1186-L1190

--

-- 
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/010701843a3db436-ee8f40f9-4da5-4eff-957c-465e565270b1-00%40eu-central-1.amazonses.com.

Re: [Django] #34135: Add async interface to ManyRelatedManager & RelatedManager

[Django]

#34135: Add async interface to ManyRelatedManager & RelatedManager
-+-
 Reporter:  Jon Janzen   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  async| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Janzen):

 FWIW I'm also willing to work on a PR for this ticket, assuming a similar
 solution to #34112.

 (apologies if this ticket is not well-formed or I missed another ticket
 that covers the same topics)

-- 
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/010701843a3b8b4f-e3839c4c-a26c-4230-9b28-535a9ec81e99-00%40eu-central-1.amazonses.com.

[Django] #34135: Add async interface to ManyRelatedManager & RelatedManager

[Django]

#34135: Add async interface to ManyRelatedManager & RelatedManager
-+-
   Reporter:  Jon|  Owner:  nobody
  Janzen |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  async
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 With #34112 and #33646 combined, there is now an async interface for
 reading/writing Models in a lot of cases. One of the obvious places where
 that isn't true is in `RelatedManager` instances. `RelatedManager`
 instances are missing async versions of:

 * `add`
 * `remove`
 * `clear`
 * `set`

 And this might be a separate ticket but the docs [1] are missing a
 reference to `acreate` which according to `dir()` exists on
 `ManyRelatedManager` (I assume as a consequence of inheriting from some
 superclass `Manager` type) but I didn't actually try and see if it works.
 I'm suspicious that it might not be fully correct as
 `related_descriptors.py` includes a possibly custom version of the
 synchronous `create` function (see [2] & [3]).

 [1]
 
https://docs.djangoproject.com/en/dev/ref/models/relations/#django.db.models.fields.related.RelatedManager
 [2]
 
https://github.com/django/django/blob/main/django/db/models/fields/related_descriptors.py#L788-L792
 [3]
 
https://github.com/django/django/blob/main/django/db/models/fields/related_descriptors.py#L1186-L1190

-- 
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/010701843a39112b-f22bad2b-795d-403d-928a-d9daaf398c5f-00%40eu-central-1.amazonses.com.

Re: [Django] #34134: Add DynamoDB engine to sessions middleware

[Django]

#34134: Add DynamoDB engine to sessions middleware
-+-
 Reporter:  matan3178|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.sessions |  Version:  4.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  session, engine, | Triage Stage:
  dynamodb   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the ticket, however a custom `SessionStore` doesn't have to be
 a part of Django itself. It sounds like a third-party package is the best
 way to proceed.

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

-- 
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/0107018439cc1fde-253eff32-3a1c-4755-acd4-e3a1188afbe9-00%40eu-central-1.amazonses.com.

[Django] #34134: Add DynamoDB engine to sessions middleware

[Django]

#34134: Add DynamoDB engine to sessions middleware
-+-
   Reporter:  matan3178  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  4.1
  contrib.sessions   |   Keywords:  session, engine,
   Severity:  Normal |  dynamodb
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have the code written here:
 https://github.com/matan3178/django_dynamodb_session_engine.git

 Just need to merge it to the Django project (Which I don't have the time
 for)

 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/0107018439bbf231-ab211170-4392-406b-a628-def81c0b818e-00%40eu-central-1.amazonses.com.

Re: [Django] #34133: Django ordering in model meta causing unexpected results of group_by

[Django]

#34133: Django ordering in model meta causing unexpected results of group_by
-+-
 Reporter:  ssobczak |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #32546, fixed in 330bc402a8d2d8f23cf2e07d9dabf333003677d3
 (Django 4.0+).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018439621b4e-68d4bd4d-4c78-4e40-84cb-871a285bad63-00%40eu-central-1.amazonses.com.

Re: [Django] #33871: JSONField with default is not detected as changed when invalidated in inlines.

[Django]

#33871: JSONField with default is not detected as changed when invalidated in
inlines.
-+-
 Reporter:  Raphael  |Owner:  JunKi
 |  Yoon
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  JSONField| Triage Stage:
  TabularInline  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David Sanders):

 Confirmed the patch for #34119 fixes the issue with sample models provided
 and steps described above.

-- 
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/01070184395acdab-3b69c2e9-c4da-4176-9aa0-7ac6b52fa280-00%40eu-central-1.amazonses.com.

Re: [Django] #30801: Improve guidance for making good use of signals.

[Django]

#30801: Improve guidance for making good use of signals.
-+-
 Reporter:  Aymeric Augustin |Owner:  Joseph V
 Type:   |  Zammit
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"018311d481d4ad949633cab1adb7677b927c8b1e" 018311d]:
 {{{
 #!CommitTicketReference repository=""
 revision="018311d481d4ad949633cab1adb7677b927c8b1e"
 [4.1.x] Fixed #30801 -- Improved guidance for making good use of signals.

 Backport of 71e9694856627d4027c9df066045f0e1c2b5cf27 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/010701843940c534-a11c2e92-2850-496f-837d-55b2ea72cef2-00%40eu-central-1.amazonses.com.

Re: [Django] #30801: Improve guidance for making good use of signals.

[Django]

#30801: Improve guidance for making good use of signals.
-+-
 Reporter:  Aymeric Augustin |Owner:  Joseph V
 Type:   |  Zammit
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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 Carlton Gibson ):

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


Comment:

 In [changeset:"71e9694856627d4027c9df066045f0e1c2b5cf27" 71e9694]:
 {{{
 #!CommitTicketReference repository=""
 revision="71e9694856627d4027c9df066045f0e1c2b5cf27"
 Fixed #30801 -- Improved guidance for making good use of signals.
 }}}

-- 
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/0107018439406242-1b67e496-876c-41dd-bf26-5b36c6d6b2cf-00%40eu-central-1.amazonses.com.

Re: [Django] #34133: Django ordering in model meta causing unexpected results of group_by

[Django]

#34133: Django ordering in model meta causing unexpected results of group_by
-+-
 Reporter:  ssobczak |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
-+-
Description changed by ssobczak:

Old description:

> For the following model:
>

> {{{
> class Product(models.Model):
>name = models.CharField()
>category = models.CharField()
>price = models.IntegerField()
>
>class Meta:
>   ordering = ("name",)
> }}}
>
> Given the following products:
>
> {{{
> Product.objects.create(name="Milk", category="Food", price="5")
> Product.objects.create(name="Cookies", category="Food", price="7")
>
> Product.objects.create(name="Table", category="Furniture", price="100")
> }}}
>

> I want to calculate average product price per category:
>
> {{{
> qs = Product.objects.values("category").annotate(avg_price=Avg("price"))
> }}}
>
> I expect to see a result like:
>
> {{{
> [
>{"category": "Food", "avg_price": 6},
>{"category": "Furniture", "avg_price": 100},
> ]
> }}}
>
> but I actually get:
> {{{
> [
>{"category": "Food", "avg_price": 5},
>{"category": "Food", "avg_price": 7},
>{"category": "Furniture", "avg_price": 100},
> ]
> }}}
>

> That's because the column "name" from model's ordering in Meta is
> automatically added to the GROUP BY part of the SQL, which causes the
> category "Food" to be duplicated in the result:
>
> {{{
> qs = Product.objects.values("category").annotate(avg_price=Avg("price"))
> print(qs.query)
>
> > SELECT
> >"x"."category",
> >AVG("x"."price") AS "avg_price"
> > FROM "x_product"
> > GROUP BY
> >"x_product"."category",
> >"x_product"."name" -- UNEXPECTED!
> }}}
>

> I know as a workaround I can "force" an empty order_by() on the queryset:
> {{{
> qs =
> Product.objects.order_by().values("category").annotate(avg_price=Avg("price"))
> }}}
>
> Remembering about this every time I run `values().annotate()` is very
> error-prone. This is the second time I'm debugging this issue in my
> current project.
>
> I think the default ordering (from model Meta) should be cleared whenever
> SQL GROUP BY is generated by the query.

New description:

 For the following model:


 {{{
 class Product(models.Model):
name = models.CharField()
category = models.CharField()
price = models.IntegerField()

class Meta:
   ordering = ("name",)
 }}}

 Given the following products:

 {{{
 Product.objects.create(name="Milk", category="Food", price=5)
 Product.objects.create(name="Cookies", category="Food", price=7)

 Product.objects.create(name="Table", category="Furniture", price=100)
 }}}


 I want to calculate average product price per category:

 {{{
 qs = Product.objects.values("category").annotate(avg_price=Avg("price"))
 }}}

 I expect to see a result like:

 {{{
 [
{"category": "Food", "avg_price": 6},
{"category": "Furniture", "avg_price": 100},
 ]
 }}}

 but I actually get:
 {{{
 [
{"category": "Food", "avg_price": 5},
{"category": "Food", "avg_price": 7},
{"category": "Furniture", "avg_price": 100},
 ]
 }}}


 That's because the column "name" from model's ordering in Meta is
 automatically added to the GROUP BY part of the SQL, which causes the
 category "Food" to be duplicated in the result:

 {{{
 qs = Product.objects.values("category").annotate(avg_price=Avg("price"))
 print(qs.query)

 > SELECT
 >"x"."category",
 >AVG("x"."price") AS "avg_price"
 > FROM "x_product"
 > GROUP BY
 >"x_product"."category",
 >"x_product"."name" -- UNEXPECTED!
 }}}


 I know as a workaround I can "force" an empty order_by() on the queryset:
 {{{
 qs =
 Product.objects.order_by().values("category").annotate(avg_price=Avg("price"))
 }}}

 Remembering about this every time I run `values().annotate()` is very
 error-prone. This is the second time I'm debugging this issue in my
 current project.

 I think the default ordering (from model Meta) should be cleared whenever
 SQL GROUP BY is generated by the 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 

[Django] #34133: Django ordering in model meta causing unexpected results of group_by

[Django]

#34133: Django ordering in model meta causing unexpected results of group_by
-+-
   Reporter:  ssobczak   |  Owner:  nobody
   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  |
-+-
 For the following model:


 {{{
 class Product(models.Model):
name = models.CharField()
category = models.CharField()
price = models.IntegerField()

class Meta:
   ordering = ("name",)
 }}}

 Given the following products:

 {{{
 Product.objects.create(name="Milk", category="Food", price="5")
 Product.objects.create(name="Cookies", category="Food", price="7")

 Product.objects.create(name="Table", category="Furniture", price="100")
 }}}


 I want to calculate average product price per category:

 {{{
 qs = Product.objects.values("category").annotate(avg_price=Avg("price"))
 }}}

 I expect to see a result like:

 {{{
 [
{"category": "Food", "avg_price": 6},
{"category": "Furniture", "avg_price": 100},
 ]
 }}}

 but I actually get:
 {{{
 [
{"category": "Food", "avg_price": 5},
{"category": "Food", "avg_price": 7},
{"category": "Furniture", "avg_price": 100},
 ]
 }}}


 That's because the column "name" from model's ordering in Meta is
 automatically added to the GROUP BY part of the SQL, which causes the
 category "Food" to be duplicated in the result:

 {{{
 qs = Product.objects.values("category").annotate(avg_price=Avg("price"))
 print(qs.query)

 > SELECT
 >"x"."category",
 >AVG("x"."price") AS "avg_price"
 > FROM "x_product"
 > GROUP BY
 >"x_product"."category",
 >"x_product"."name" -- UNEXPECTED!
 }}}


 I know as a workaround I can "force" an empty order_by() on the queryset:
 {{{
 qs =
 Product.objects.order_by().values("category").annotate(avg_price=Avg("price"))
 }}}

 Remembering about this every time I run `values().annotate()` is very
 error-prone. This is the second time I'm debugging this issue in my
 current project.

 I think the default ordering (from model Meta) should be cleared whenever
 SQL GROUP BY is generated by the 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/01070184393d30c4-d410d4a6-6aa2-44b8-9275-fb2260a71797-00%40eu-central-1.amazonses.com.

Re: [Django] #30801: Improve guidance for making good use of signals.

[Django]

#30801: Improve guidance for making good use of signals.
-+-
 Reporter:  Aymeric Augustin |Owner:  Joseph V
 Type:   |  Zammit
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Carlton Gibson):

 * 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/0107018438e55a72-3f4a1baa-5f03-4d84-b222-d6040c32cd65-00%40eu-central-1.amazonses.com.

Re: [Django] #33586: Cannot delete object (A) referenced by another object (B) if said object (A) has a foreign key to a custom user.

[Django]

#33586: Cannot delete object (A) referenced by another object (B) if said object
(A) has a foreign key to a custom user.
---+
 Reporter:  Jeremy Poulin  |Owner:  Bhuvnesh
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Carlton Gibson):

 Reading the issue, you've not addressed the points in
 https://code.djangoproject.com/ticket/33586#comment:19 (and previous to
 that).

 > Do you have any numbers to support your performance claim? This is
 important as you are forcing the eviction of a cache layer dedicated to
 making performance better.

 Creating some benchmarks (using pyperf perhaps) looks like a step forward.


 From comment:15

 > You should be able to demonstrate and explain why this change is needed
 by writing a minimal test case from the issue reported by Jeremy that can
 be integrated to the suite and demonstrates the origin of the issue. From
 there we'd need numbers on the effect it has has on performance to
 determine if that's the right place to make the changes.

 So there's a couple of avenues already, but there were other points made.

-- 
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/01070184385fce29-443eeb18-096b-4c9c-a5c3-032855c7f22d-00%40eu-central-1.amazonses.com.

Re: [Django] #33586: Cannot delete object (A) referenced by another object (B) if said object (A) has a foreign key to a custom user.

[Django]

#33586: Cannot delete object (A) referenced by another object (B) if said object
(A) has a foreign key to a custom user.
---+
 Reporter:  Jeremy Poulin  |Owner:  Bhuvnesh
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Bhuvnesh):

 Can someone please provide some feedback on 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/01070184382b8045-91abd363-9f20-49b6-950f-9b6cbd5515b8-00%40eu-central-1.amazonses.com.

Re: [Django] #33984: Related managers cache gets stale after saving a fetched model with new PK

[Django]

#33984: Related managers cache gets stale after saving a fetched model with new 
PK
-+-
 Reporter:  joeli|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"57c2e5da710b583110d8c7c20e91774a61d7472f" 57c2e5d]:
 {{{
 #!CommitTicketReference repository=""
 revision="57c2e5da710b583110d8c7c20e91774a61d7472f"
 Refs #33984 -- Added test for creating copies of model instances with
 inherited m2m fields.
 }}}

-- 
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/01070184381bc4ed-d83a3251-7050-4760-a457-7d4698720d0e-00%40eu-central-1.amazonses.com.

Re: [Django] #34132: Migration with CheckConstraint fails on PostgreSQL in PyPy with psycopg2cffi due to AttributeError

[Django]

#34132: Migration with CheckConstraint fails on PostgreSQL in PyPy with
psycopg2cffi due to AttributeError
-+-
 Reporter:  Henryk Plötz |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, however `psycopg2cffi` is not officially supported.
 Moreover, it's compatible with `psycopg2==2.5` (according to its `README`)
 and Django 4.1 supports `psycopg2` `2.8.4` or higher. You should report
 this on the `psycopg2cffi` bug tracker.

-- 
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/0107018437fad599-da18c978-1496-41c9-af60-0112961ce67c-00%40eu-central-1.amazonses.com.

[Django] #34132: Migration with CheckConstraint fails on PostgreSQL in PyPy with psycopg2cffi due to AttributeError

[Django]

#34132: Migration with CheckConstraint fails on PostgreSQL in PyPy with
psycopg2cffi due to AttributeError
-+-
   Reporter:  Henryk |  Owner:  nobody
  Plötz  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  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  |
-+-
 == Description

 `quote_value` in `django/db/backends/postgresql/schema.py` assigns to
 `adapted.encoding`. This is not allowed in psycopg2cffi and raises an
 AttributeError.

 The code path was added in #31815

 I'm not sure what the correct fix would be. Simply not assigning
 `encoding` seems wrong. Is what the code tries even possible in cffi?

 == Steps to reproduce

 (I'm using poetry. Also needs `apt-get install libpq-dev pypy3 pypy3-dev`
 or equivalent.)

 {{{
 poetry new demo
 cd demo
 poetry env use `which pypy3`
 poetry add django psycopg2cffi
 rm -rf demo
 poetry run django-admin startproject demo
 cd demo
 poetry run ./manage.py startapp demo1
 }}}

 in `demo/settings.py` add

 {{{
 from psycopg2cffi import compat
 compat.register()
 }}}

 and add `demo1` to `INSTALLED_APPS`

 in `demo1/models.py` add


 {{{
 from django.db import models

 # Create your models here.

 class Demo1(models.Model):
   dummy = models.CharField(max_length=23)
   class Meta:
 constraints = [
   models.CheckConstraint(name="dummy",
 check=models.Q(dummy__in=["a","b"]))
 ]
 }}}

 then run


 {{{
 poetry run ./manage.py makemigrations
 }}}


 The file `demo1/migrations/0001_initial.py` now contains


 {{{
 # Generated by Django 4.1.3 on 2022-11-02 10:25

 from django.db import migrations, models


 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='Demo1',
 fields=[
 ('id', models.BigAutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('dummy', models.CharField(max_length=23)),
 ],
 ),
 migrations.AddConstraint(
 model_name='demo1',
 constraint=models.CheckConstraint(check=models.Q(('dummy__in',
 ['a', 'b'])), name='dummy'),
 ),
 ]
 }}}

 Now configure settings for a postgres database (in `demo/settings.py`)


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'demo',
 "USER": "demo",
 "PASSWORD": "",
 "HOST": "",
 }
 }
 }}}

 and run


 {{{
 poetry run ./manage.py migrate
 }}}


 == Actual results


 {{{
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, demo1, sessions
 Running migrations:
   Applying contenttypes.0001_initial... OK
   Applying auth.0001_initial... OK
   Applying admin.0001_initial... OK
   Applying admin.0002_logentry_remove_auto_add... OK
   Applying admin.0003_logentry_add_action_flag_choices... OK
   Applying contenttypes.0002_remove_content_type_name... OK
   Applying auth.0002_alter_permission_name_max_length... OK
   Applying auth.0003_alter_user_email_max_length... OK
   Applying auth.0004_alter_user_username_opts... OK
   Applying auth.0005_alter_user_last_login_null... OK
   Applying auth.0006_require_contenttypes_0002... OK
   Applying auth.0007_alter_validators_add_error_messages... OK
   Applying auth.0008_alter_user_username_max_length... OK
   Applying auth.0009_alter_user_last_name_max_length... OK
   Applying auth.0010_alter_group_name_max_length... OK
   Applying auth.0011_update_proxy_permissions... OK
   Applying auth.0012_alter_user_first_name_max_length... OK
   Applying demo1.0001_initial...Traceback (most recent call last):
   File "./manage.py", line 22, in 
 main()
   File "./manage.py", line 18, in main
 execute_from_command_line(sys.argv)
   File "/home/henryk/.cache/pypoetry/virtualenvs/demo-gWrR8tCo-
 py3.8/lib/pypy3.8/site-packages/django/core/management/__init__.py", line
 446, in execute_from_command_line
 utility.execute()
   File "/home/henryk/.cache/pypoetry/virtualenvs/demo-gWrR8tCo-
 py3.8/lib/pypy3.8/site-packages/django/core/management/__init__.py", line
 440, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/henryk/.cache/pypoetry/virtualenvs/demo-gWrR8tCo-
 py3.8/lib/pypy3.8/site-packages/django/core/management/base.py", line 402,
 in run_from_argv
 self.execute(*args, **cmd_options)
   File 

Re: [Django] #23577: Rename operations should rename indexes, constraints, sequences and triggers named after their former value

[Django]

#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
-+
 Reporter:  Chris Woytowitz  |Owner:  (none)
 Type:  Bug  |   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:  0|UI/UX:  0
-+

Comment (by scholtalbers):

 Encountered this (django 3.2) when trying to add a field with the same
 name of a field I renamed in a few migrations before. The original index
 is still existing. It should have been renamed as part of the AlterField
 migration.

-- 
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/0107018437e17f8e-a0426515-d170-447b-8d5f-eb77373f52a7-00%40eu-central-1.amazonses.com.

Re: [Django] #34119: ModelForm fields with callable defaults don't correctly propagate default values

[Django]

#34119: ModelForm fields with callable defaults don't correctly propagate 
default
values
-+-
 Reporter:  Benjamin Rigaud  |Owner:  David Sanders
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  modelform| 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):

 #33871 was a duplicate for `JSONField`.

-- 
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/0107018437d4f92f-f901e2a0-8205-4374-a035-1ff1b67f49fc-00%40eu-central-1.amazonses.com.

Re: [Django] #33871: JSONField with default is not detected as changed when invalidated in inlines.

[Django]

#33871: JSONField with default is not detected as changed when invalidated in
inlines.
-+-
 Reporter:  Raphael  |Owner:  JunKi
 |  Yoon
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  JSONField| Triage Stage:
  TabularInline  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => duplicate
 * stage:  Accepted => Unreviewed


Comment:

 Duplicate of #34119.

-- 
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/0107018437d46fd0-944e8d57-3cd7-439b-8677-847eb21bc8d6-00%40eu-central-1.amazonses.com.

Re: [Django] #31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if request.user is not unwrapped in sync code

[Django]

#31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if
request.user is not unwrapped in sync code
--+
 Reporter:  Michael Galler|Owner:  lirontb
 Type:  New feature   |   Status:  assigned
Component:  contrib.sessions  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:  async | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Adam Johnson):

 I don’t like the suggestion of adding `SimpleLazyObject.__await__`. It’s
 too “magical” and it makes the type of `request.user` complex.

 Currently django-stubs types `request.user` as `User | AnonymousUser`
 (with a documented technique to use just `User`
 [https://github.com/typeddjango/django-stubs#how-can-i-create-a
 -httprequest-thats-guaranteed-to-have-an-authenticated-user for logged in
 requests]). If we wanted to support the `__await__` method in type hints,
 then the type would become `User | AnonymousUser | Awaitable[[], User |
 AnonymousUser]`. This would require [https://adamj.eu/tech/2021/05/17
 /python-type-hints-how-to-narrow-types-with-isinstance-assert-literal/
 type narrowing] everywhere `request.user` is used... so, we probably
 wouldn’t want to do that in django-stubs, but that would make it harder to
 have a correctly type-checked async Django app.

 I propose instead making the middleware add a coroutine `request.auser()`
 that fetches from `request.user`, used like:

 {{{
 user = await request.auser()
 if user.is_authenticated:
 ...
 }}}

 Yes, it’s a little more code, but it follows Django’s other async API’s
 and it looks like a normal coroutine call.

-- 
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/0107018437d1acbc-437d0eb6-3942-4b33-bdb2-1ba344477338-00%40eu-central-1.amazonses.com.

Re: [Django] #34131: Postgres AutoField change from serial to identity

[Django]

#34131: Postgres AutoField change from serial to identity
-+-
 Reporter:  Marco Glauser|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (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 Florian Apolloner):

 * cc: Florian Apolloner (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/0107018437b7ab2e-6bc1500e-abf8-4bf1-af97-914c2317b4d6-00%40eu-central-1.amazonses.com.

Re: [Django] #34112: Add async interface to Model

[Django]

#34112: Add async interface to Model
-+-
 Reporter:  Adam Johnson |Owner:  Bhuvnesh
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"d5bcdf858d962d02de925603c17986980f03729a" d5bcdf85]:
 {{{
 #!CommitTicketReference repository=""
 revision="d5bcdf858d962d02de925603c17986980f03729a"
 Fixed #34112 -- Added async-compatible interface to Model methods.

 Thanks Adam Johnson for the review.
 }}}

-- 
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/0107018437ab7c12-6d757e5f-b6da-48b1-9812-3fccf988788a-00%40eu-central-1.amazonses.com.

Re: [Django] #34129: Admin list_editable failed to edit

[Django]

#34129: Admin list_editable failed to edit
---+--
 Reporter:  Djing  |Owner:  Djing
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  duplicate
 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:  assigned => closed
 * resolution:   => duplicate


Comment:

 This is a duplicate of #33375: if you **really** need this pattern define
 a form class with the id, using the desired queryset, so that
 `BaseModelFormSet.add_fields()` doesn't add the field with the default
 manager.

 David is on track: you need to be extra careful with setting default
 managers that filter the QuerySet.

-- 
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/0107018437a9e180-fcdf1d6f-a6c2-4ae0-a113-84fe64b1ef7f-00%40eu-central-1.amazonses.com.

Re: [Django] #34112: Add async interface to Model

[Django]

#34112: Add async interface to Model
-+-
 Reporter:  Adam Johnson |Owner:  Bhuvnesh
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/01070184376909c2-e3546019-cfac-4325-b651-b74f109f6e08-00%40eu-central-1.amazonses.com.

Re: [Django] #34054: Create a topic about fixtures

[Django]

#34054: Create a topic about fixtures
-+-
 Reporter:  Filip Łajszczak  |Owner:  Filip
 Type:   |  Łajszczak
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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 ):

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


Comment:

 In [changeset:"6103059592c6c1bd171977d26b76ee475175043c" 61030595]:
 {{{
 #!CommitTicketReference repository=""
 revision="6103059592c6c1bd171977d26b76ee475175043c"
 Fixed #34054 -- Created a new fixtures topic.

 Moved material from django-admin document into a new document, and
 added new material.

 Co-authored-by: Mariusz Felisiak 
 }}}

-- 
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/010701843767e136-36579439-7a57-4921-b072-e002e4cf83ee-00%40eu-central-1.amazonses.com.

Re: [Django] #34054: Create a topic about fixtures

[Django]

#34054: Create a topic about fixtures
-+-
 Reporter:  Filip Łajszczak  |Owner:  Filip
 Type:   |  Łajszczak
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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/01070184372ca403-3fd06465-7ef1-4524-b46f-4a06711f0704-00%40eu-central-1.amazonses.com.