Re: [Django] #34657: Testing assertions `assertContains` and `assertInHTML` should output the haystack on failure

[Django]

#34657: Testing assertions `assertContains` and `assertInHTML` should output the
haystack on failure
-+-
 Reporter:  Thibaud Colas|Owner:  Chinmoy
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  HTML, assertions,| Triage Stage:  Accepted
  testing|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chinmoy):

 * needs_tests:  1 => 0


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

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

Re: [Django] #34806: Make cached_db backend resilient to cache backend errors

[Django]

#34806: Make cached_db backend resilient to cache backend errors
-+-
 Reporter:  Claude Paroz |Owner:  Sulabh
 Type:   |  Katila
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Sanders):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  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/0107018a591966f2-6047fffb-d507-4cc9-adaa-3aac132fae7d-00%40eu-central-1.amazonses.com.

Re: [Django] #34811: Queryset filter Q order changed

[Django]

#34811: Queryset filter Q order changed
-+-
 Reporter:  Edward Villegas- |Owner:  nobody
  Pulgarin   |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  filter, Q| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 If that can be of any help, we've observed that MySQL's query planer is
 can be pretty bad at using composite indexes when `OR` conditions are
 involved and had to resort to using `UNION` to target them.

 Re-writing your lookup to move the `filling_id=pk` outside of the `OR`
 should help MySQL at figuring out that the `filing_id` index can be used
 at least.

 {{{#!python
 TaxInput.objects.filter(
 filling_id=pk,
 Q(updated_at__gt=last_engine.created_at) |
 Q(deleted__gt=last_engine.created_at)
 )
 }}}

 {{{#!sql
 SELECT
   *
 FROM
   `taxobjects_taxinput`
 WHERE
 `taxobjects_taxinput` . `filling_id` = ?
 AND (
 `taxobjects_taxinput` . `updated_at` > ?
 OR `taxobjects_taxinput` . `deleted` > ?
 )
 LIMIT
   ?
 }}}

-- 
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/0107018a58c428ff-37e250cd-a9f8-4df3-bb88-616f0d1c1854-00%40eu-central-1.amazonses.com.

Re: [Django] #34811: Queryset filter Q order changed

[Django]

#34811: Queryset filter Q order changed
-+-
 Reporter:  Edward Villegas- |Owner:  nobody
  Pulgarin   |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  filter, Q| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Sanders):

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


Comment:

 Hi,

 Thanks for the report though I don't see an issue with Django here. There
 are many reasons why a database will choose to ignore indexes but sadly
 parameter ordering is not one of those. (To test this I recreated your
 setup and MySQL reported that the indexes are a possibility both ways.)

 I'd encourage you to seek help from one of the Django support channels
 where there are many friendly people who are eager to help:
 https://www.djangoproject.com/community/

 You'll likely need to paste detailed descriptions of your models, query,
 setup & any query plans (you may even be asked to paste memory settings
 etc as this will have an impact on query planning).

 If it is discovered there is an issue with Django feel free to reopen this
 with links to discussion & findings.

 Good luck!

-- 
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/0107018a589a6f43-d364699c-edd8-4158-ae60-1fd66bb0042d-00%40eu-central-1.amazonses.com.

Re: [Django] #33277: SimpleTestCase does not block database connections in threads

[Django]

#33277: SimpleTestCase does not block database connections in threads
-+-
 Reporter:  Daniel Hahler|Owner:  Sulabh
 |  Katila
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 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 Sulabh Katila):

 Hello David,

 Thank you for getting the ball rolling on this feature! I've looked at the
 PR, and it's impressive. I'll definitely use it as inspiration to continue
 the work. If you have any specific insights or tips based on your progress
 so far, please feel free to share.
 I'm looking forward to working on this together!

 Replying to [comment:4 David Wobrock]:
 > Hey Sulabh,
 >
 > I see you assigned yourself the ticket, that's great!
 > I've started a [https://github.com/django/django/pull/17075 PR] some
 months ago, feel free to check it out if it can give you some inspiration
 :)

-- 
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/0107018a586c7b76-92796f38-3c76-4cec-931e-731f29c4acdc-00%40eu-central-1.amazonses.com.

[Django] #34811: Queryset filter Q order changed

[Django]

#34811: Queryset filter Q order changed
-+-
   Reporter: |  Owner:  nobody
  cosmoscalibur  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  filter, Q
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Using filters in order explicitly expressed by user is important because
 take advantage of indexes.

 When apply this query


 {{{
 TaxInput.objects.all(
 force_visibility=True
 ).filter(
 Q(filling_id=pk, updated_at__gt=last_engine.created_at)
 | Q(filling_id=pk, deleted__gt=last_engine.created_at),
 )
 }}}


 the MySQL generated query is


 {{{
 SELECT
   *
 FROM
   `taxobjects_taxinput`
 WHERE
   ( `taxobjects_taxinput` . `filling_id` = ?
 AND `taxobjects_taxinput` . `updated_at` > ? )
   OR ( `taxobjects_taxinput` . `deleted` > ?
 AND `taxobjects_taxinput` . `filling_id` = ? )
 LIMIT
   ?
 }}}


 But should be


 {{{
 SELECT
   *
 FROM
   `taxobjects_taxinput`
 WHERE
   ( `taxobjects_taxinput` . `filling_id` = ?
 AND `taxobjects_taxinput` . `updated_at` > ? )
   OR ( `taxobjects_taxinput` . `filling_id` > ?
 AND `taxobjects_taxinput` . `deleted` = ? )
 LIMIT
   ?
 }}}

 This change of order create a 10x factor in query time, because this table
 has index filing_id, and also index (filing_id, deleted).

 Using Django 4.2.1 and SafeDelete 1.3.1 (because this is used
 force_visibility=True in all manager).

-- 
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/0107018a571c0873-85aff85e-c75b-4620-9de8-ec856edb17da-00%40eu-central-1.amazonses.com.

Re: [Django] #33277: SimpleTestCase does not block database connections in threads

[Django]

#33277: SimpleTestCase does not block database connections in threads
-+-
 Reporter:  Daniel Hahler|Owner:  Sulabh
 |  Katila
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 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 David Wobrock):

 * cc: David Wobrock (added)


Comment:

 Hey Sulabh,

 I see you assigned yourself the ticket, that's great!
 I've started a [https://github.com/django/django/pull/17075 PR] some
 months ago, feel free to check it out if it can give you some inspiration
 :)

-- 
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/0107018a56f5fe24-231fc6f2-940d-4e3b-b5e4-36fd38042cde-00%40eu-central-1.amazonses.com.

Re: [Django] #34808: Some aggregation functions may return None; this isn't well documented

[Django]

#34808: Some aggregation functions may return None; this isn't well documented
--+
 Reporter:  Eric Baumgartner  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  4.2
 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 Eric Baumgartner):

 Ah, thanks, I completely missed that `default` was an option. (In 4.0, at
 least -- I"m still working with some 3.2 projects.)

 I'm happy to take a shot at some documentation changes. I haven't
 contributed to Django before, so if you have any pointers for newbies I'd
 appreciate it.

 Now that I've reviewed #10929 (and I know what to look for) I think
 coverage is better than I'd originally thought. I think the main things
 I'd address include:

 - Reviewing all example code across pages that uses `.aggregate(...)` and
 adding an explicit `default` param or `None` handling when appropriate. I
 think this is important because many people grab the sample code and don't
 read additional documentation.
 - On the aggregation topic page specifically, add a new section ("Handling
 empty querysets"?) that discusses `default` and explains that it uses
 Coalesce under the hood.
 - Add something to the documentation of `Aggregation.default` on the
 querysets page mentioning that it uses Coalesce under the hood.

 Does that scope make sense?

 I think mentioning Coalesce is helpful because it provides a hint for
 pre-4 users who can't use `default`. Is that sort of thing OK? I don't
 know what the project's position is on mentioning stuff that only applies
 to older versions.

 Somewhat related, should the documentation for `default` have a "New in
 4.0" flag? Or are those flags reserved for just changed in the last
 release or two?

-- 
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/0107018a56b633d4-ae693958-e2de-4833-ba5e-287ff396-00%40eu-central-1.amazonses.com.

[Django] #34810: Calculate coverage on subprocesses such as django-admin commands

[Django]

#34810: Calculate coverage on subprocesses such as django-admin commands
+
   Reporter:  Jacob Walls   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Noticed during #34778 that despite good coverage for the django-admin
 commands in `tests/admin_scripts`, the coverage report suggests only 12%
 coverage for `django/core/management/templates.py`.

 This is because using coverage.py to trace code launched by a subprocess
 (and not through multiprocessing) requires
 [https://coverage.readthedocs.io/en/stable/subprocess.html additional
 configuration], e.g. adding code to sitecustomize.py or creating a .pth
 file.

 Perhaps we could look into creating a tempdir with a .pth file to run the
 needed coverage.py configuration while running tests.

-- 
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/0107018a55ff44bc-2ea33fcf-804f-4d3b-8b83-fc17ed1c649f-00%40eu-central-1.amazonses.com.