Re: [Django] #33747: Display exception notes on the technical 500 debug page on Python 3.11+. (was: Display exception notes in in the technical 500 debug page on Python 3.11+.)

2022-05-27 Thread Django
#33747: Display exception notes on the technical 500 debug page on Python 3.11+.
-+--
 Reporter:  Adam Johnson |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  4.1
 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
-+--

-- 
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/01070181076435e8-4009415b-541a-4d7f-9380-7ebd0bf9cb52-00%40eu-central-1.amazonses.com.


Re: [Django] #32894: isinstance() checks with non-configured LazySettings raise an exception.

2022-05-27 Thread Django
#32894: isinstance() checks with non-configured LazySettings raise an exception.
-+-
 Reporter:  simon klemenc|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  lazyobject   | Triage Stage:
  lazysettings   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Keryn Knight):

 Continuing to document new ways in which I come across this (always niche,
 naturally) in case there ever comes a tipping point where it's potentially
 ''worth'' investigating options further.

 Running:
 {{{
 monkeytype run -m runtests --parallel=1
 }}}
 against the Django test suite generates a lot of log noise like so:
 {{{
 Failed collecting trace
 Traceback (most recent call last):
   File "/path/to/python3.10/site-packages/monkeytype/tracing.py", line
 259, in __call__
 self.handle_call(frame)
   File "/path/to/python3.10/site-packages/monkeytype/tracing.py", line
 213, in handle_call
 func = self._get_func(frame)
   File "/path/to/python3.10/site-packages/monkeytype/tracing.py", line
 207, in _get_func
 self.cache[code] = get_func(frame)
   File "/path/to/python3.10/site-packages/monkeytype/tracing.py", line
 156, in get_func
 if not isinstance(v, type):
   File "/path/to/django/utils/functional.py", line 294, in
 __getattribute__
 value = super().__getattribute__(name)
   File "/path/to/django/utils/functional.py", line 266, in inner
 self._setup()
   File "/path/to/django/conf/__init__.py", line 72, in _setup
 raise ImproperlyConfigured(
 django.core.exceptions.ImproperlyConfigured: Requested settings, but
 settings are not configured. You must either define the environment
 variable DJANGO_SETTINGS_MODULE or call settings.configure() before
 accessing settings.
 }}}
 They all seem to be log messages which may not actually present as an
 error/problem in practice, though (that is, the test suite looks to
 continue running ... but I gave up on it as it was taking forever)

-- 
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/0107018106e06851-b68f12e8-49b6-44b9-8a35-fa21738c17e4-00%40eu-central-1.amazonses.com.


Re: [Django] #33701: Highlight error location in the technical 500 debug page on Python 3.11+.

2022-05-27 Thread Django
#33701: Highlight error location in the technical 500 debug page on Python 
3.11+.
-+-
 Reporter:  Adam Johnson |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  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
-+-
Changes (by Keryn Knight):

 * cc: Keryn Knight (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/0107018106572d0c-d9920291-d7f0-4b96-83e9-55d536e20915-00%40eu-central-1.amazonses.com.


Re: [Django] #33701: Highlight error location in the technical 500 debug page on Python 3.11+.

2022-05-27 Thread Django
#33701: Highlight error location in the technical 500 debug page on Python 
3.11+.
-+-
 Reporter:  Adam Johnson |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  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 Adam Johnson):

 Relatedly I also opened #33747 to show exception notes, another feature in
 Python 3.11

-- 
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/01070181062a13c5-86f5f0f4-6993-470c-848b-7d232f52f225-00%40eu-central-1.amazonses.com.


[Django] #33747: Display exception notes in in the technical 500 debug page on Python 3.11+.

2022-05-27 Thread Django
#33747: Display exception notes in in the technical 500 debug page on Python 
3.11+.
---+
   Reporter:  Adam Johnson |  Owner:  (none)
   Type:  New feature  | Status:  new
  Component:  Error reporting  |Version:  4.1
   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|
---+
 Similar to #33701's suggestion to extend the debug page.

 Python 3.11 adds `BaseException.__notes__` which may include extra
 information about the exception. These are expected to be used by certain
 libraries that can attach context to exceptions.

 https://docs.python.org/3.11/whatsnew/3.11.html#exceptions-can-be-
 enriched-with-notes-pep-678

 The default Python error handler displays these. Django's debug page
 should too, to aid debugging.

-- 
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/010701810629b99d-b8fcc582-4889-4fe2-b016-a29c2a0bb232-00%40eu-central-1.amazonses.com.


Re: [Django] #33308: Add psycopg3 backend

2022-05-27 Thread 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 Mika):

 * cc: Mika (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/0107018105b96a14-1eaac6e0-2fa5-42db-a43b-1e6a29a984e3-00%40eu-central-1.amazonses.com.


Re: [Django] #31788: Models migration with change field foreign to many and deleting unique together.

2022-05-27 Thread Django
#31788: Models migration with change field foreign to many and deleting unique
together.
+-
 Reporter:  budzichd|Owner:  David Wobrock
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  3.0
 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):

 * cc: David Wobrock (added)
 * owner:  nobody => David Wobrock
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 Quite a funny bug actually in the autodetector and how we sort migration
 with respect to their dependencies.
 I can't exactly reproduce the described output, but something similar.

 Here is a little dive into the issue.

 When changing a field from FK to M2M, the autodetector goes within
 
`django.db.migrations.autodetector.MigrationAutodetector.generate_altered_fields`
 and creates a `RemoveField`+`AddField`, which is fine and works.
 But we also generate a `AlterUniqueTogether`...

 Since we call `generate_removed_altered_unique_together` before
 `generate_altered_fields`, one would expect it to work as expected.
 And at first, we have the right operation order: `[AlterUniqueTogether,
 RemoveField, AddField]`.

 However, when sorting the operations with respect to their dependencies,
 we trigger the dependency that `RemoveField` should be after
 `AlterUniqueTogether`.
 Even if this condition is already satisfied, the `stable_topological_sort`
 changes the order and returns `[AlterUniqueTogether, AddField,
 RemoveField]`. The dependency is still satisfied, but our Remove/Add
 became an Add/Remove, which cannot work.
 In `tests/utils_tests/test_topological_sort.py`
 {{{
 def test_preserve_satisfied_order(self):
 dependency_graph = {1: set(), 2: {1}, 3: set()}
 self.assertEqual(
 stable_topological_sort([1, 2, 3], dependency_graph),
 [1, 2, 3],
 )
 }}}
 return
 {{{
 ==
 FAIL: test_preserve_satisfied_order
 (utils_tests.test_topological_sort.TopologicalSortTests)
 --
 Traceback (most recent call last):
   File "/home/david/django/tests/utils_tests/test_topological_sort.py",
 line 29, in test_preserve_satisfied_order
 self.assertEqual(
 AssertionError: Lists differ: [1, 3, 2] != [1, 2, 3]

 First differing element 1:
 3
 2

 - [1, 3, 2]
 + [1, 2, 3]
 }}}
 on my env (and since we rely on sets, I suspect that's why I don't have
 the same result as described in the ticket. I think that's why Simon is
 seeing a `[AddField, AlterUniqueTogether, RemoveField]`, which also
 satisfies the dependencies).

 (on top of that, the autodetector then optimizes the operations, and the
 `AddField` followed by `RemoveField` cancel each other out, and we end up
 with a single `[AlterUniqueTogether]`).

 Two possible approaches to fix this:
 1. Making the `AddField` depend on `RemoveField`, so that we force their
 order
 2. Changing the topological sort, so that it preserves the input order as
 much as possible

 Since the second might imply a large set of changes, so I tried
 implementing the first one in this
 [https://github.com/django/django/pull/15738 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/0107018105b881e1-04663909-0f5e-46fa-b13b-10cbc5d7779c-00%40eu-central-1.amazonses.com.


Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

2022-05-27 Thread Django
#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Fabio Caritas Barrionuevo da Luz):

 * cc: Fabio Caritas Barrionuevo da Luz (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/0107018104f8ea32-8d2a9b59-d51b-43a8-9245-b54e57196bac-00%40eu-central-1.amazonses.com.


Re: [Django] #33746: [ORM] queryset.query return a string that makes MySQLDB to fail with error "not enough arguments for format string"

2022-05-27 Thread Django
#33746: [ORM] queryset.query return a string that makes MySQLDB to fail with 
error
"not enough arguments for format string"
-+-
 Reporter:  Juanmi Taboada   |Owner:  nobody
 Type:  Bug  |   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 Carlton Gibson):

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


Comment:

 Duplicate of #25705

-- 
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/01070181046787f4-964a5fbb-7ddf-460f-9ab8-51a9130f85e8-00%40eu-central-1.amazonses.com.


[Django] #33746: [ORM] queryset.query return a string that makes MySQLDB to fail with error "not enough arguments for format string"

2022-05-27 Thread Django
#33746: [ORM] queryset.query return a string that makes MySQLDB to fail with 
error
"not enough arguments for format string"
-+-
   Reporter:  Juanmi |  Owner:  nobody
  Taboada|
   Type:  Bug| Status:  new
  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  |
-+-
 Recently I faced an error when getting a query with **queryset.query**.

 The resultant string had inside "**%**" (percentage character) for **LIKES
 clauses** and **MySQLDB** module at is actual version is rendering the
 query using:
 {{{
 query = query % args
 }}}


 Example of the wrong a QUERY I got from **queryset.query** rendering:
 {{{
 SELECT DISTINCT products_becaseeker.beca_id,
 `products_becaseeker`.`status`  FROM `products_becaseeker` INNER JOIN
 `products_becapublic` ON (`products_becaseeker`.`beca_id` =
 `products_becapublic`.`beca_id`) WHERE
 (`products_becapublic`.`convenor_id` = 246 OR
 `products_becapublic`.`convenor_id` = 34 OR
 LOWER(JSON_UNQUOTE(`products_becaseeker`.`convenor_others`)) LIKE
 LOWER(%"246"%) OR
 LOWER(JSON_UNQUOTE(`products_becaseeker`.`convenor_others`)) LIKE
 LOWER(%"34"%)) AND MATCH(products_becaseeker.keywords) AGAINST
 (\'(comunidad* madrid*) ("comunidad de madrid") ("comunidad de madrid")
 (comunidad madrid)\' IN BOOLEAN MODE)  ORDER BY products_becaseeker.status
 DESC
 }}}
 the offending part is:
 {{{
 ... LIKE LOWER(%"246"%) ...
 ... LIKE LOWER(%"34"%) ...
 }}}

 I believe the right string to be render in **MySQLDB** should be:
 {{{
 ... LIKE LOWER("%%246%%") ...
 ... LIKE LOWER("%%34%%") ...
 }}}



 The error I verified it is happening in **Django 4.0.2** together with
 **Python 3.9** at **MySQLdb/cursors.py, line 201**

 The short quick solution was to replace those with the right ones:
 {{{
 .replace('(%"', '("%%').replace('"%)', '%%")')
 }}}

 and it worked like a charm,  but I believe the query rendered should be
 aware about how MySQLDB is rendering 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/01070181042ebccc-c10cd2a8-6742-497d-ab19-adf8593787a7-00%40eu-central-1.amazonses.com.