Re: [Django] #27550: add version of GEOSGeometry.normalize() that returns new geometry

[Django]

#27550: add version of GEOSGeometry.normalize() that returns new geometry
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Marcelo
 |  Galigniana
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marcelo Galigniana):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180c057c95d-fb6eff65-146d-4c1f-8ebc-edebd2fc5c59-00%40eu-central-1.amazonses.com.

Re: [Django] #33705: IsNull() lookup cannot be used directly in filters.

[Django]

#33705: IsNull() lookup cannot be used directly in filters.
-+-
 Reporter:  Florian Apolloner|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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 David Wobrock):

 * cc: David Wobrock (added)
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 Here is a draft [https://github.com/django/django/pull/15692 PR] with
 failing tests.
 Just a quick shot, trying to fix the issue with the approach of letting
 the `IsNull` handle `Value` objects internally instead of `bool`s. But
 that might have quite a large impact for such a small change.

-- 
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/01070180bf620763-1ca00ecf-7202-46e2-af05-0a0dc770354f-00%40eu-central-1.amazonses.com.

Re: [Django] #33308: Add psycopg3 backend

[Django]

#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Thiago Bellini Ribeiro):

 * cc: Thiago Bellini Ribeiro (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/01070180bf2e30eb-8d4acc29-429e-45a0-b3fc-d5fd818530b4-00%40eu-central-1.amazonses.com.

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

[Django]

#27064: Implement RenameIndex in a backwards compatible way
-+-
 Reporter:  Markus Holtermann|Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * needs_better_patch:  1 => 0


Comment:

 Rebased [https://github.com/django/django/pull/15651 PR], ready for some
 review again :)
 Even if it (most probably) won't be included to the coming 4.1 release.

-- 
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/01070180befa6144-ff245132-1420-4186-988a-391092264415-00%40eu-central-1.amazonses.com.

Re: [Django] #33707: Allow Oracle table names to be over 30 characters

[Django]

#33707: Allow Oracle table names to be over 30 characters
-+-
 Reporter:  Scott Ertel  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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 #30684.

-- 
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/01070180be90bbf8-0a23d42c-e923-4133-a54e-b6487ac96657-00%40eu-central-1.amazonses.com.

Re: [Django] #33685: Tests crash when using only a service name on PostgreSQL.

[Django]

#33685: Tests crash when using only a service name on PostgreSQL.
---+
 Reporter:  Shane Ambler   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Hasan Ramezani):

 > however, my draft patch is quite complex and the risk of introducing
 regressions in a stable version is too great,

 Agree with you.

 > I'd document that service names cannot be currently used for testing
 purposes and treat this as a new feature request.

 Sound good to me.

-- 
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/01070180be774b5b-0b0cbb36-fa94-4588-9cfa-c7bea7bd6c4a-00%40eu-central-1.amazonses.com.

Re: [Django] #33706: Implement subquery annotations as (lateral) joins (was: Implement annotations as (lateral) joins)

[Django]

#33706: Implement subquery annotations as (lateral) joins
-+-
 Reporter:  Bálint Balina|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  annotate,performance,subquery,postgresql|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 To answer your questions I believe it would be doable to adjust the SQL
 compilers to have subquery annotations to rely on lateral joins but I'm
 not sure doing it by default on all engines that support it will be
 beneficial given the amount of work necessary to achieve it.

 Some database engine will optimize away computed expressions with the same
 identity if they are specified multiple times. The article you linked
 provides no proof that this is actually beneficial in anyway beyond SQL
 DRY-ness (no `EXPLAIN` output, no benchmarks) which isn't the ORM's main
 focus. The SO article is also barely related to this issue, sure it hacks
 into the compiler internals to use a `LATERAL` join but it has nothing to
 do with subquery annotation handling.

 This ticket tracker is used to manage accepted and confirmed issues, I
 suggest you use [https://docs.djangoproject.com/en/4.0/internals/mailing-
 lists/#django-developers the developer mailing list] to request feedback
 on this feature request. I suggest providing proof about claimed
 performance benefits and details about implementation database engines
 that Django currently supports to gather positive traction for your
 proposal. Without them it's unlikely that work that specialize the way
 subquery annotation works and complexify the SQL compiler will be
 accepted. Searching this ticket tracker, mailing lists, and Github for
 keywords such as `subquery` and `lateral` might also help you gather
 context on the subject.

 I'll close this issue in the mean time as further discussion and
 investigation is required before we can accept this work.

-- 
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/01070180bdcf4ade-ceed245a-6662-4b70-b4d3-7707fca10f54-00%40eu-central-1.amazonses.com.

[Django] #33707: Allow Oracle table names to be over 30 characters

[Django]

#33707: Allow Oracle table names to be over 30 characters
-+-
   Reporter:  Scott  |  Owner:  nobody
  Ertel  |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  4.0
  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  |
-+-
 Currently django.db.backends.oracle sets the max length of a table to 30
 characters, and models with names longer than that are hashed. This makes
 it difficult for users of the database  (i.e. analytics users) to work
 with the tables in their queries.

 Oracle has allowed characters over 30 length since 12.2, and Django
 supports versions 19c and higher.

 I change this behavior through a monkey patch:

 {{{
 DatabaseOperations.max_name_length = lambda x: 128
 }}}

 I was wondering if the length could be specified in the config and the
 max_name_length function could be changed to use that setting, or default
 to 30 if not set?

 I would like to contribute the change if possible.

-- 
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/01070180bdb8817d-84aa1705-555c-4292-9b6c-9151942aecb1-00%40eu-central-1.amazonses.com.

Re: [Django] #8408: Add a new meta option: don't do count(*) in admin

[Django]

#8408: Add a new meta option: don't do count(*) in admin
---+---
 Reporter:  LI Daobing |Owner:  Thomas Chaumeny
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  dev
 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 msphn):

 I couldn't find any good solution so I build myself a custom paginator.

 My database is mysql using innodb, I made use of innodb to get a fast and
 precise enough count of rows. Please be aware, that this might not be
 precise enough for everyone's usecase.

 My paginator shouldn't be understood as a patch, but it's an adequate
 workaround to speed up your django admin. I had no problem with that, and
 I can now easily browse my 5 million+ datasets.

 {{{#!python
 from django.core.paginator import Paginator

 from django.utils.functional import cached_property
 from django.db import connection


 class MysqlInnoDbPaginator(Paginator):
 @cached_property
 def count(self):
 with connection.cursor() as cursor:
 cursor.execute(
 "SELECT TABLE_ROWS FROM information_schema.tables WHERE
 TABLE_SCHEMA = %s AND TABLE_NAME = %s;",
 [connection.settings_dict['NAME'],
 self.object_list.model._meta.db_table]
 )

 row = cursor.fetchone()

 if row is not None:
 return row[0]
 else:
 return 0
 }}}


 Add this to your admin.ModelAdmin implementation. The
 show_full_result_count is very important, otherwise another count would
 happen.

 {{{#!python
 class FoobarAdmin(admin.ModelAdmin):
 paginator = MysqlInnoDbPaginator
 show_full_result_count = False
 }}}

 Also be aware, if you have multiple database configurations, you should
 modify it so it would find the right database name

-- 
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/01070180bd81c17d-ba8a5de7-9695-4cf2-9864-ea9468428a09-00%40eu-central-1.amazonses.com.

Re: [Django] #33706: Implement annotations as (lateral) joins

[Django]

#33706: Implement annotations as (lateral) joins
-+-
 Reporter:  Bálint Balina|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  annotate,performance,subquery,postgresql|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Bálint Balina:

Old description:

> The ORM annotations are a very good and flexible tool for dynamic data.
> However there is a huge performance loss because of the way they are
> implemented. See the following example:
>

> {{{
> Product.objects.annotate(
> on_stock=Subquery(
> Stock.objects.filter(
> product_id=OuterRef('id'),
> ).values('product_id').annotate(
> on_stock=Sum('quantity'),
> ).values('on_stock').order_by(),
> output_field=DecimalField(),
> ),
> outgoing=Subquery(
> OrderItem.objects.filter(
> product_id=OuterRef('id'),
> ).values('product_id').annotate(
> outgoing=Sum('quantity'),
> ).values('outgoing').order_by(),
> output_field=DecimalField(),
> ),
> available=F('on_stock') - F('outgoing'),
> ).filter(
> available__gt=0,
> ).values('id', 'on_stock', 'outgoing', 'available')
> }}}
>
> When aggregates are needed from multiple tables annotation can be used as
> subqueries. Annotations can also be filtered against and reused. However
> django implements this query with the following SQL:
>

> {{{
> SELECT "product"."id",
>(SELECT SUM(u0."quantity") AS "on_stock"
> FROM "stock" u0
> WHERE ( u0."product_id" = ("product"."id"))
> GROUP BY u0."product_id")AS
> "on_stock",
>(SELECT SUM(u0."quantity") AS "outgoing"
> FROM "order_item" u0
> WHERE u0."product_id" = ("product"."id")
> GROUP BY u0."product_id")AS
> "outgoing",
>((SELECT SUM(u0."quantity") AS "on_stock"
>  FROM "stock" u0
>  WHERE (u0."product_id" = ("product"."id"))
>  GROUP BY u0."product_id") - (SELECT SUM(u0."quantity") AS
> "outgoing"
>   FROM "order_item" u0
>   WHERE u0."product_id" =
> ("product"."id")
>   GROUP BY u0."product_id")) AS
> "available"
> FROM "product"
> WHERE (((SELECT SUM(u0."quantity") AS "on_stock"
>  FROM "stock" u0
>  WHERE (u0."product_id" = ("product"."id"))
>  GROUP BY u0."product_id") - (SELECT SUM(u0."quantity") AS
> "outgoing"
>   FROM "order_item" u0
>   WHERE u0."product_id" =
> ("product"."id")
>   GROUP BY u0."product_id")) > 0)
> }}}
>
> Both the on_stock and outgoing annotations are inlined 3 times and
> calculated 3 times by the database, which is 6 subquery instead of 2.
>
> See the following PostgreSQL query adjusted by hand:
>
> {{{
> SELECT "product"."id",
>"on_stock",
>"outgoing",
>"on_stock" - "outgoing" as available
> FROM "product"
>, LATERAL (SELECT SUM(u0."quantity") AS "on_stock"
>   FROM "stock" u0
>   WHERE (u0."product_id" = ("product"."id"))
>   GROUP BY u0."product_id") AS "on_stock"
>, LATERAL (SELECT SUM(u0."quantity") AS "outgoing"
>   FROM "order_item" u0
>   WHERE u0."product_id" = ("product"."id")
>   GROUP BY u0."product_id") AS "outgoing"
> WHERE (("on_stock" - "outgoing") > 0)
> }}}
>
> The exact same subquery can be joined with the lateral keyword, producing
> the exact same results, but reusing calculations. The performance benefit
> is huge, it can be hundreds of milliseconds even for this simple query,
> even more so the more complicated and reused these calculations are.
>
> I like the way annotate works, there are many small pieces to put
> together to get a complex result. I'm planning to look into implementing
> this behaviour, but wanted to check first about your opinions:
>
> - do you think it is possible to patch the ORM to generate sql like
> above?
> - do you see any pitfalls or caveats to this method of performing the
> query?
> - if there are no pitfalls, or they can be resolved do you think that
> this could be the default way of 

[Django] #33706: Implement annotations as (lateral) joins

[Django]

#33706: Implement annotations as (lateral) joins
-+-
   Reporter:  Bálint |  Owner:  nobody
  Balina |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  4.0
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  annotate,performance,subquery,postgresql
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The ORM annotations are a very good and flexible tool for dynamic data.
 However there is a huge performance loss because of the way they are
 implemented. See the following example:


 {{{
 Product.objects.annotate(
 on_stock=Subquery(
 Stock.objects.filter(
 product_id=OuterRef('id'),
 ).values('product_id').annotate(
 on_stock=Sum('quantity'),
 ).values('on_stock').order_by(),
 output_field=DecimalField(),
 ),
 outgoing=Subquery(
 OrderItem.objects.filter(
 product_id=OuterRef('id'),
 ).values('product_id').annotate(
 outgoing=Sum('quantity'),
 ).values('outgoing').order_by(),
 output_field=DecimalField(),
 ),
 available=F('on_stock') - F('outgoing'),
 ).filter(
 available__gt=0,
 ).values('id', 'on_stock', 'outgoing', 'available')
 }}}

 When aggregates are needed from multiple tables annotation can be used as
 subqueries. Annotations can also be filtered against and reused. However
 django implements this query with the following SQL:


 {{{
 SELECT "product"."id",
(SELECT SUM(u0."quantity") AS "on_stock"
 FROM "stock" u0
 WHERE ( u0."product_id" = ("product"."id"))
 GROUP BY u0."product_id")AS
 "on_stock",
(SELECT SUM(u0."quantity") AS "outgoing"
 FROM "order_item" u0
 WHERE u0."product_id" = ("product"."id")
 GROUP BY u0."product_id")AS
 "outgoing",
((SELECT SUM(u0."quantity") AS "on_stock"
  FROM "stock" u0
  WHERE (u0."product_id" = ("product"."id"))
  GROUP BY u0."product_id") - (SELECT SUM(u0."quantity") AS
 "outgoing"
   FROM "order_item" u0
   WHERE u0."product_id" =
 ("product"."id")
   GROUP BY u0."product_id")) AS
 "available"
 FROM "product"
 WHERE (((SELECT SUM(u0."quantity") AS "on_stock"
  FROM "stock" u0
  WHERE (u0."product_id" = ("product"."id"))
  GROUP BY u0."product_id") - (SELECT SUM(u0."quantity") AS
 "outgoing"
   FROM "order_item" u0
   WHERE u0."product_id" =
 ("product"."id")
   GROUP BY u0."product_id")) > 0)
 }}}

 Both the on_stock and outgoing annotations are inlined 3 times and
 calculated 3 times by the database, which is 6 subquery instead of 2.

 See the following PostgreSQL query adjusted by hand:

 {{{
 SELECT "product"."id",
"on_stock",
"outgoing",
"on_stock" - "outgoing" as available
 FROM "product"
, LATERAL (SELECT SUM(u0."quantity") AS "on_stock"
   FROM "stock" u0
   WHERE (u0."product_id" = ("product"."id"))
   GROUP BY u0."product_id") AS "on_stock"
, LATERAL (SELECT SUM(u0."quantity") AS "outgoing"
   FROM "order_item" u0
   WHERE u0."product_id" = ("product"."id")
   GROUP BY u0."product_id") AS "outgoing"
 WHERE (("on_stock" - "outgoing") > 0)
 }}}

 The exact same subquery can be joined with the lateral keyword, producing
 the exact same results, but reusing calculations. The performance benefit
 is huge, it can be hundreds of milliseconds even for this simple query,
 even more so the more complicated and reused these calculations are.

 I like the way annotate works, there are many small pieces to put together
 to get a complex result. I'm planning to look into implementing this
 behaviour, but wanted to check first about your opinions:

 - do you think it is possible to patch the ORM to generate sql like above?
 - do you see any pitfalls or caveats to this method of performing the
 query?
 - if there are no pitfalls, or they can be resolved do you think that this
 could be the default way of annotating calculations in django? The
 examples are in postgresql, not sure about the other supported database
 engines compatibility.

-- 
Ticket URL: 

Re: [Django] #29748: Add AUTH_GROUP_MODEL setting to swap the group model

[Django]

#29748: Add AUTH_GROUP_MODEL setting to swap the group model
--+-
 Reporter:  damoncheng|Owner:  damoncheng
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by Gian Luca Decurtins):

 Who will take a decision on the PR? Is there anyone I could try to reach
 out to?

-- 
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/01070180bd30ae11-24e153e5-7a8b-47f2-99c9-f08fc8a1e96f-00%40eu-central-1.amazonses.com.

Re: [Django] #33681: Cache OPTIONS are not passed to the Redis client.

[Django]

#33681: Cache OPTIONS are not passed to the Redis client.
-+-
 Reporter:  Ben Picolo   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180bd22197f-d3e99e78-cd02-4064-b8c7-0419cce806a9-00%40eu-central-1.amazonses.com.

Re: [Django] #33685: Tests crash when using only a service name on PostgreSQL.

[Django]

#33685: Tests crash when using only a service name on PostgreSQL.
---+
 Reporter:  Shane Ambler   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * cc: Hasan Ramezani, Carlton Gibson (added)


Comment:

 I've tried to implement this but all mechanism related with
 creating/cloning test databases are based on the database name. It's
 feasible, however, my draft patch is quite complex and the risk of
 introducing regressions in a stable version is too great, IMO. I'd
 document that service names cannot be currently used for testing purposes
 and treat this as a new feature request.

 For example:
 {{{#!diff
 diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
 index c270f56942..ca6362a7a6 100644
 --- a/docs/ref/databases.txt
 +++ b/docs/ref/databases.txt
 @@ -165,6 +165,11 @@ password from the `password file`_, you must specify
 them in the
  Support for connecting by a service name, and specifying a password
 file
  was added.

 +.. warning::
 +
 +Using a service name for testing purposes is not supported. This
 +:ticket:`may be implemented later <33685>`.
 +
  Optimizing PostgreSQL's configuration
  -


 }}}

-- 
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/01070180bd1f0b05-74f4d857-7c5e-49e5-90b7-699559fc6301-00%40eu-central-1.amazonses.com.

Re: [Django] #33691: Deprecate CryptPasswordHasher.

[Django]

#33691: Deprecate CryptPasswordHasher.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   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 Mariusz Felisiak):

 Agreed, we can at least deprecate `SHA1PasswordHasher`,
 `UnsaltedMD5PasswordHasher`, `UnsaltedSHA1PasswordHasher` before the
 feature freeze.
 Please `Refs #33691 -- ...` in your patch.

-- 
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/01070180bd0db11c-3041040c-f82f-4c0f-9c4d-16c33d6d63fe-00%40eu-central-1.amazonses.com.

Re: [Django] #33705: IsNull() lookup cannot be used directly in filters. (was: IsNull-Lookup not usable)

[Django]

#33705: IsNull() lookup cannot be used directly in filters.
-+-
 Reporter:  Florian Apolloner|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180bcbf04c9-2213c541-0b45-464f-a785-1c4a0fe33d15-00%40eu-central-1.amazonses.com.

Re: [Django] #33704: Missing migrations in postgres_tests tests.

[Django]

#33704: Missing migrations in postgres_tests tests.
-+-
 Reporter:  Florian Apolloner|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   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
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"c112f837d4960b68e912e23139bb97ef01c870a6" c112f837]:
 {{{
 #!CommitTicketReference repository=""
 revision="c112f837d4960b68e912e23139bb97ef01c870a6"
 Fixed #33704 -- Updated postgres_tests migrations.
 }}}

-- 
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/01070180bcbb14f3-866798ac-cbbc-49e8-bec9-480e367704fc-00%40eu-central-1.amazonses.com.

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

[Django]

#33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement
---+--
 Reporter:  Maxim Danilov  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  4.0
 Severity:  Normal |   Resolution:  invalid
 Keywords:  admin, modeladmin  | 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:

 Exactly as you quoted the docs:
 > The get_fields method is given the HttpRequest and the obj being edited
 (or None on an add form) and is expected to **return a list of fields, as
 described above in the ModelAdmin.fields** section.

 and `ModelAdmin.fields`:

 > **Use the fields option to make simple layout changes** in the forms on
 the “add” and “change” pages such as showing only a subset of available
 fields **For more complex layout needs, see the fieldsets option.**

 You didn't use `ModelAdmin.fields` or overwrite `ModelAdmin.get_fields()`,
 so `ModelAdmin.get_fields()` returned base fields and readonly-fields.
 `ModelAdmin.get_fields()` is not described as a tool for getting displayed
 fields, it's a hook to overwrite displayed fields when you need a
 conditional logic based on a request and you don't use `fieldsets` for a
 complex layout, not the other way around.

 You can raise your doubts on the DevelopersMailingList to reach a wider
 audience and see what other think, if you don't agree. 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/01070180bcb107c3-7e37d8f8-0c55-45d1-be9e-8b287dedfe2a-00%40eu-central-1.amazonses.com.

[Django] #33705: IsNull-Lookup not usable

[Django]

#33705: IsNull-Lookup not usable
-+-
   Reporter:  Florian|  Owner:  nobody
  Apolloner  |
   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  |
-+-
 The docs in
 
https://docs.djangoproject.com/en/4.0/ref/models/lookups/#django.db.models.Lookup
 seem to suggest that
 {{{
 __=
 }}}
 is somewhat equivalent to
 {{{
 (, )
 }}}

 This does work for some lookups, but not for `IsNull`:

 {{{
 >>> from django.contrib.auth.models import User
 >>> from django.db.models import F
 >>> from django.db.models.lookups import GreaterThan, IsNull
 >>> User.objects.filter(GreaterThan(F('pk'), 1000))
 DEBUG 2022-05-13 10:45:10,907 utils 63853 (0.006) SELECT "auth_user"."id",
 "auth_user"."password", "auth_user"."last_login",
 "auth_user"."is_superuser", "auth_user"."username",
 "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
 "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined"
 FROM "auth_user" WHERE "auth_user"."id" > (1000) LIMIT 21; args=(1000,);
 alias=default
 
 >>> User.objects.filter(IsNull(F('pk'), True))
 Traceback (most recent call last):
   File "", line 1, in 
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/manager.py",
 line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/query.py",
 line 1071, in filter
 return self._filter_or_exclude(False, args, kwargs)
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/query.py",
 line 1089, in _filter_or_exclude
 clone._filter_or_exclude_inplace(negate, args, kwargs)
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/query.py",
 line 1096, in _filter_or_exclude_inplace
 self._query.add_q(Q(*args, **kwargs))
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/sql/query.py",
 line 1502, in add_q
 clause, _ = self._add_q(q_object, self.used_aliases)
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/sql/query.py",
 line 1532, in _add_q
 child_clause, needed_inner = self.build_filter(
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/sql/query.py",
 line 1370, in build_filter
 condition = filter_expr.resolve_expression(self,
 allow_joins=allow_joins)
   File
 
"/home/florian/dev/bap/observer/server/__pypackages__/3.10/lib/django/db/models/lookups.py",
 line 174, in resolve_expression
 c.rhs = self.rhs.resolve_expression(
 AttributeError: 'bool' object has no attribute 'resolve_expression'
 }}}

-- 
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/01070180bc9a8723-012c3374-e3c4-4343-b1b5-341d47d7a897-00%40eu-central-1.amazonses.com.

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

[Django]

#33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement
---+--
 Reporter:  Maxim Danilov  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords:  admin, modeladmin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Maxim Danilov):

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


Comment:

 documentation:
 
 ModelAdmin.get_fields
 The get_fields method is given the HttpRequest and the obj being edited
 (or None on an add form) and is expected to return a list of fields, as
 described above in the ModelAdmin.fields section.

 ModelAdmin.fields

 Use the fields option to make simple layout changes in the forms on the
 “add” and “change” pages such as showing only a subset of available fields
 For more complex layout needs, see the fieldsets option.
 

 I use only .fieldsets, without .fields definition.  ModelAdmin.get_fields
 give me a wrong list.
 Why you set my ticket as 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/01070180bc86fed0-b6873c08-eb7e-4378-b343-bec4e61932e9-00%40eu-central-1.amazonses.com.

Re: [Django] #33697: Cleanup duplication of HTTP header parsing in utils.http and multipart parser.

[Django]

#33697: Cleanup duplication of HTTP header parsing in utils.http and multipart
parser.
--+
 Reporter:  Carlton Gibson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 Hi Kapil.

 There's already some coverage, so making the change ensuring the existing
 tests pass would be a start.

 On implementation, you may find you need to adjust tests, or add new ones.
 That's OK.

 If we need extra tests after that, they can be suggested on review.

 The [https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 code/submitting-patches/ Submitting patches] guide should help you on your
 next steps.

 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/01070180bc610d12-9b41799f-97d1-4fd7-a2d8-76d5079ecfb4-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

[Django]

#33682: Clarify using distinct() with related fields that have Meta.ordering
defined.
--+
 Reporter:  Robert Leach  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  sql, distinct | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 I think Mariusz' suggestion is more appropriate. I don't think the more
 discursive "gotcha"-type content fits in the reference documentation,
 rather than a more tutorial like piece, where it would be better. (Perhaps
 a blog post if there's no spot we yet discuss this in that kind of
 context.)

 I think the **solution** here comes back to Simon's comment:1…

 > ...error out loudly so at least users are not presented this cryptic
 error.

 If we could catch this and present an error showing the field mismatch
 folks would be able to correct at source. (That's totally Blue Skies — no
 idea how easy building a better error message is here.)

 (I think like Mariusz, I'd lean heavily towards the ''raise'' option,
 rather than trying to implicitly do/guess the right thing™ here.)

 HTH

-- 
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/01070180bc5d60f4-74dd7b9f-ffd6-44f4-9bf9-2d6c1ba32d57-00%40eu-central-1.amazonses.com.

Re: [Django] #33704: Missing migrations in postgres_tests tests.

[Django]

#33704: Missing migrations in postgres_tests tests.
-+-
 Reporter:  Florian Apolloner|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180bc59f1f5-1ce3ecef-5d55-4d9d-8a86-32bc6939cdef-00%40eu-central-1.amazonses.com.

Re: [Django] #33704: Missing migrations in postgres_tests tests. (was: Missing migrations in tests)

[Django]

#33704: Missing migrations in postgres_tests tests.
---+
 Reporter:  Florian Apolloner  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180bc3e1c3e-0826645c-bfab-486c-a771-ae525dce9344-00%40eu-central-1.amazonses.com.

Re: [Django] #33704: Missing migrations in tests

[Django]

#33704: Missing migrations in tests
---+--
 Reporter:  Florian Apolloner  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Florian Apolloner:

Old description:

> Running
> ```
> ./runtests.py --settings=test_postgresql -v2
> postgres_tests.test_search.TestRankingAndWeights.test_ranked_custom_weights
> --keepdb
> ```
>
> with the following settings:
> ```
> DATABASES = {
> "default": {
> "ENGINE": "django.db.backends.postgresql",
> "NAME": "django",
> },
> "other": {
> "ENGINE": "django.db.backends.postgresql",
> "NAME": "django2",
> },
> }
>
> # INSTALLED_APPS = [
> #'postgres_tests',
> # ]
>
> SECRET_KEY = "django_tests_secret_key"
>
> # Use a fast hasher to speed up tests.
> PASSWORD_HASHERS = [
> "django.contrib.auth.hashers.MD5PasswordHasher",
> ]
>
> DEFAULT_AUTO_FIELD = "django.db.models.AutoField"
>
> USE_TZ = False
> ```
>
> results in:
> ```
> Testing against Django installed in
> '/home/florian/sources/django.git/django' with up to 16 processes
> Importing application postgres_tests
> Found 1 test(s).
> Skipping setup of unused database(s): other.
> Using existing test database for alias 'default' ('test_django')...
> Operations to perform:
>   Synchronize unmigrated apps: auth, contenttypes, messages, sessions,
> staticfiles
>   Apply all migrations: admin, postgres_tests, sites
> Synchronizing apps without migrations:
>   Creating tables...
> Running deferred SQL...
> Running migrations:
>   No migrations to apply.
>   Your models in app(s): 'postgres_tests' have changes that are not yet
> reflected in a migration, and so won't be applied.
>   Run 'manage.py makemigrations' to make new migrations, and then re-run
> 'manage.py migrate' to apply them.
> System check identified no issues (0 silenced).
> test_ranked_custom_weights
> (postgres_tests.test_search.TestRankingAndWeights) ... ok
> ```
>
> We should investigate why we miss migrations here.

New description:

 Running
 {{{
 ./runtests.py --settings=test_postgresql -v2
 postgres_tests.test_search.TestRankingAndWeights.test_ranked_custom_weights
 --keepdb
 }}}

 with the following settings:
 {{{
 DATABASES = {
 "default": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "django",
 },
 "other": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "django2",
 },
 }

 # INSTALLED_APPS = [
 #'postgres_tests',
 # ]

 SECRET_KEY = "django_tests_secret_key"

 # Use a fast hasher to speed up tests.
 PASSWORD_HASHERS = [
 "django.contrib.auth.hashers.MD5PasswordHasher",
 ]

 DEFAULT_AUTO_FIELD = "django.db.models.AutoField"

 USE_TZ = False
 }}}

 results in:
 {{{
 Testing against Django installed in
 '/home/florian/sources/django.git/django' with up to 16 processes
 Importing application postgres_tests
 Found 1 test(s).
 Skipping setup of unused database(s): other.
 Using existing test database for alias 'default' ('test_django')...
 Operations to perform:
   Synchronize unmigrated apps: auth, contenttypes, messages, sessions,
 staticfiles
   Apply all migrations: admin, postgres_tests, sites
 Synchronizing apps without migrations:
   Creating tables...
 Running deferred SQL...
 Running migrations:
   No migrations to apply.
   Your models in app(s): 'postgres_tests' have changes that are not yet
 reflected in a migration, and so won't be applied.
   Run 'manage.py makemigrations' to make new migrations, and then re-run
 'manage.py migrate' to apply them.
 System check identified no issues (0 silenced).
 test_ranked_custom_weights
 (postgres_tests.test_search.TestRankingAndWeights) ... ok
 }}}

 We should investigate why we miss migrations here.

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180bc2cfb05-555038ec-68c8-43bc-a57a-0d75f241e2dc-00%40eu-central-1.amazonses.com.

[Django] #33704: Missing migrations in tests

[Django]

#33704: Missing migrations in tests
-+
   Reporter:  Florian Apolloner  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  dev
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Running
 ```
 ./runtests.py --settings=test_postgresql -v2
 postgres_tests.test_search.TestRankingAndWeights.test_ranked_custom_weights
 --keepdb
 ```

 with the following settings:
 ```
 DATABASES = {
 "default": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "django",
 },
 "other": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "django2",
 },
 }

 # INSTALLED_APPS = [
 #'postgres_tests',
 # ]

 SECRET_KEY = "django_tests_secret_key"

 # Use a fast hasher to speed up tests.
 PASSWORD_HASHERS = [
 "django.contrib.auth.hashers.MD5PasswordHasher",
 ]

 DEFAULT_AUTO_FIELD = "django.db.models.AutoField"

 USE_TZ = False
 ```

 results in:
 ```
 Testing against Django installed in
 '/home/florian/sources/django.git/django' with up to 16 processes
 Importing application postgres_tests
 Found 1 test(s).
 Skipping setup of unused database(s): other.
 Using existing test database for alias 'default' ('test_django')...
 Operations to perform:
   Synchronize unmigrated apps: auth, contenttypes, messages, sessions,
 staticfiles
   Apply all migrations: admin, postgres_tests, sites
 Synchronizing apps without migrations:
   Creating tables...
 Running deferred SQL...
 Running migrations:
   No migrations to apply.
   Your models in app(s): 'postgres_tests' have changes that are not yet
 reflected in a migration, and so won't be applied.
   Run 'manage.py makemigrations' to make new migrations, and then re-run
 'manage.py migrate' to apply them.
 System check identified no issues (0 silenced).
 test_ranked_custom_weights
 (postgres_tests.test_search.TestRankingAndWeights) ... ok
 ```

 We should investigate why we miss migrations here.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180bc2c58e8-3eb64707-ed4c-4def-a220-f1877f54f1c3-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

[Django]

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Florian Apolloner (added)
 * stage:  Unreviewed => Accepted


Comment:

 OK, thanks for the follow-up, and PR Anders. I'll Accept for review so we
 can get some eyes on it.

 (I didn't think it through 100% yet, or look at the reasons for the
 previous changes, but I have mentally queried at times the reason for the
 APPEND_SLASH check in process request, so I'm happy to have a further look
 in any case.)

-- 
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/01070180bc12d197-3e3b6b2b-b820-42e2-a837-c1b03c0fced4-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

[Django]

#33682: Clarify using distinct() with related fields that have Meta.ordering
defined.
--+
 Reporter:  Robert Leach  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  sql, distinct | 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: Carlton Gibson (added)


Comment:

 It seems we need a second option about the wording.

-- 
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/01070180bc066761-a77e3b13-b9e4-4a75-b478-5fd457d47f05-00%40eu-central-1.amazonses.com.