[Django] #35251: dumpdata refactoring

[Django]

#35251: dumpdata refactoring
-+-
   Reporter:  Hovi   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  5.0
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 As far as I know, there is not more granular control over dumping database
 fixtures.
 I need to create fixtures in a more controlled fashion so I will do my own
 management command, I basically gotta copy-paste whole dumpdata management
 commant code and then modify relatively small part of it while keeping the
 rest the same.

 The main logic of `dumpdata` it is directly in `handle` method, which
 makes it impossible to reuse. I'd like to refactor contents of this method
 into smaller methods so that I can reuse some of it and make it easier to
 use dumping functionality.

 Is that something that would be welcome?
-- 
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/0107018ddf221b4c-8dd354ae-5f7d-4aaa-821a-5b0194c461ea-00%40eu-central-1.amazonses.com.

Re: [Django] #10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

[Django]

#10403: provide declarative syntax to define FormSets - including ModelFormSet 
and
InlineFormSet
-+-
 Reporter:  Koen Biermans|Owner:  Mitchina
|
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
  modelformset inlineformset |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mitchina):

 I opened a PR (still in draft) to continue the work initiated by Parth
 Patil on: https://github.com/django/django/pull/17905
-- 
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/0107018ddf03cebf-2adbc0aa-2df6-48b2-b52f-3c72959cb8bb-00%40eu-central-1.amazonses.com.

Re: [Django] #35241: Cache Model._meta.get_parent_list()

[Django]

#35241: Cache Model._meta.get_parent_list()
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Johnson):

 * needs_better_patch:  1 => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018ddd606b5e-cee9bbf7-0a84-403f-afa1-20290bb3-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HeejunShin):

  Could i try this ticket?
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018ddce5fb32-226b9b33-6d5b-4177-9f83-0a245504bd29-00%40eu-central-1.amazonses.com.

Re: [Django] #34533: OuterRef not resolved as part oh ORDER BY clause

[Django]

#34533: OuterRef not resolved as part oh ORDER BY clause
-+-
 Reporter:  REGNIER Guillaume|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  OuterRef, OrderBy| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HeejunShin):

 Thank you for answer.
 I'll consider it further.
-- 
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/0107018ddce16f88-13bb2a3e-c67c-4fbb-9e53-6f17427ad336-00%40eu-central-1.amazonses.com.

Re: [Django] #35233: Push templates checks down to backend engine classes

[Django]

#35233: Push templates checks down to backend engine classes
-+-
 Reporter:  Adam Johnson |Owner:  Giannis
 Type:   |  Terzopoulos
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 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 Adam Johnson):

 The staticfiles finders checks are actually the perfect template:

 
https://github.com/django/django/blob/35e63b7f2896959d3f1939346fd467af92f0d80f/django/contrib/staticfiles/checks.py#L11-L21
 
https://github.com/django/django/blob/35e63b7f2896959d3f1939346fd467af92f0d80f/django/contrib/staticfiles/finders.py#L23-L27
 
https://github.com/django/django/blob/35e63b7f2896959d3f1939346fd467af92f0d80f/django/contrib/staticfiles/finders.py#L74
-- 
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/0107018ddcd1b0f2-d900f81a-105a-4820-8e20-2b3066e00448-00%40eu-central-1.amazonses.com.

Re: [Django] #35250: Stop URL system checks from compiling regular expressions

[Django]

#35250: Stop URL system checks from compiling regular expressions
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Adam Johnson:

Old description:

> Continuing my project to optimize the system checks, I found some good
> optimizations under  `django.core.checks.urls.check_url_config()`, which
> showed up as quite expensive in profiling.
>
> Looking down the call tree, it seems the most expensive part of this
> process is compiling the each URL pattern’s regular expression. This is
> unnecessary work though, as the checks only need *uncompiled* regular
> expression patterns. Using the compiled versions “undoes” the lazy-
> compile optimization that `LocaleRegexDescriptor` was created for in
> #27453 / 6e222dae5636f875c19ec66f730a4241abe33faa, at least for any
> process that runs checks.
>
> The checks were fetching the uncompiled pattern with
> `self.regex.pattern`, which makse `LocaleRegexDescriptor`  compile the
> pattern only to then read the uncompiled pattern from
> [https://docs.python.org/3.12/library/re.html#re.Pattern.pattern its
> pattern attribute].
>
> Additionally, `RoutePattern` was calling `_route_to_regex()` twice to
> fetch its two result variables in different places: once in `__init__()`
> and again in `_compile()` (in the non-translated case). This function has
> non-trivial cost so avoiding double execution is worth it.
>
> Before optimization stats:
>
> * `check_url_config` took 67ms, or ~10% of the time for checks.
> * `LocaleRegexDescriptor.__get__()` showed 965 calls taking ~60ms, ~9% of
> the total runtime of checks.
> * `re.compile()` showed 741 calls for 94ms.
> * `_route_to_regex()` had 1900 calls taking 18ms (~2.6% of the total
> runtime).
>
> After optimization:
>
> * `check_url_config()` took 5ms, ~0.9% of the new total runtime.
> * The calls to `LocaleRegexDescriptor.__get__` are gone.
> * `re.compile()` drops to 212 calls from other sites, for a total of
> 51ms.
> * `_route_to_regex()` drops to the expected 950 calls, taking half the
> time at 9ms.

New description:

 Continuing my project to optimize the system checks, I found some good
 optimizations under  `django.core.checks.urls.check_url_config()`, which
 showed up as quite expensive in profiling.

 Looking down the call tree, it seems the most expensive part of this
 process is compiling the each URL pattern’s regular expression. This is
 unnecessary work though, as the checks only need *uncompiled* regular
 expression patterns. Using the compiled versions “undoes” the lazy-compile
 optimization that `LocaleRegexDescriptor` was created for in #27453 /
 6e222dae5636f875c19ec66f730a4241abe33faa, at least for any process that
 runs checks.

 The checks were fetching the uncompiled pattern with `self.regex.pattern`,
 which makse `LocaleRegexDescriptor`  compile the pattern only to then read
 the uncompiled pattern from
 [https://docs.python.org/3.12/library/re.html#re.Pattern.pattern its
 pattern attribute].

 Additionally, `RoutePattern` was calling `_route_to_regex()` twice to
 fetch its two result variables in different places: once in `__init__()`
 and again in `_compile()` (in the non-translated case). This function has
 non-trivial cost so avoiding double execution is worth it.

 Before optimization stats:

 * `check_url_config` took 67ms, or ~10% of the time for checks.
 * `LocaleRegexDescriptor.__get__()` showed 965 calls taking ~60ms, ~9% of
 the total runtime of checks.
 * `re.compile()` showed 741 calls for 94ms.
 * `_route_to_regex()` had 1900 calls taking 18ms (~2.6% of the total
 runtime).

 After optimization:

 * `check_url_config()` took 5ms, ~0.9% of the new total runtime.
 * The calls to `LocaleRegexDescriptor.__get__` are gone.
 * `re.compile()` drops to 212 calls from other sites, for a total of 51ms.
 * `_route_to_regex()` drops to the expected 950 calls, taking half the
 time at 9ms.

 (I also tried benchmarking with django-asv but got inconclusive results
 where change was within the error margins.)

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

-- 
You received this message 

Re: [Django] #35250: Stop URL system checks from compiling regular expressions

[Django]

#35250: Stop URL system checks from compiling regular expressions
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Adam Johnson:

Old description:

> Continuing my project to optimize the system checks, I found some good
> optimizations under  `django.core.checks.urls.check_url_config()`, which
> showed up as quite expensive in profiling.
>
> Looking down the call tree, it seems the most expensive part of this
> process is compiling the each URL pattern’s regular expression. This is
> unnecessary work though, as the checks only need *uncompiled* regular
> expression patterns. Using the compiled versions “undoes” the lazy-
> compile optimization that `LocaleRegexDescriptor` was created for in
> #27453 / 6e222dae5636f875c19ec66f730a4241abe33faa, at least for any
> process that runs checks.
>
> The checks were fetching the uncompiled pattern with
> `self.regex.pattern`, which makse `LocaleRegexDescriptor`  compile the
> pattern only to then read the uncompiled pattern from
> [https://docs.python.org/3.12/library/re.html#re.Pattern.pattern its
> pattern attribute].
>
> Additionally, `RoutePattern` was calling `_route_to_regex()` twice to
> fetch its two result variables in different places: once in `__init__()`
> and again in `_compile()`. This function is non-trivial.
>
> Before optimization stats:
>
> * `check_url_config` took 67ms, or ~10% of the time for checks.
> * `LocaleRegexDescriptor.__get__()` showed 965 calls taking ~60ms, ~9% of
> the total runtime of checks.
> * `re.compile()` showed 741 calls for 94ms.
> * `_route_to_regex()` had 1900 calls taking 18ms (~2.6% of the total
> runtime).
>
> After optimization:
>
> * `check_url_config()` took 5ms, ~0.9% of the new total runtime.
> * The calls to `LocaleRegexDescriptor.__get__` are gone.
> * `re.compile()` drops to 212 calls from other sites, for a total of
> 51ms.
> * `_route_to_regex()` drops to the expected 950 calls, taking half the
> time at 9ms.

New description:

 Continuing my project to optimize the system checks, I found some good
 optimizations under  `django.core.checks.urls.check_url_config()`, which
 showed up as quite expensive in profiling.

 Looking down the call tree, it seems the most expensive part of this
 process is compiling the each URL pattern’s regular expression. This is
 unnecessary work though, as the checks only need *uncompiled* regular
 expression patterns. Using the compiled versions “undoes” the lazy-compile
 optimization that `LocaleRegexDescriptor` was created for in #27453 /
 6e222dae5636f875c19ec66f730a4241abe33faa, at least for any process that
 runs checks.

 The checks were fetching the uncompiled pattern with `self.regex.pattern`,
 which makse `LocaleRegexDescriptor`  compile the pattern only to then read
 the uncompiled pattern from
 [https://docs.python.org/3.12/library/re.html#re.Pattern.pattern its
 pattern attribute].

 Additionally, `RoutePattern` was calling `_route_to_regex()` twice to
 fetch its two result variables in different places: once in `__init__()`
 and again in `_compile()` (in the non-translated case). This function has
 non-trivial cost so avoiding double execution is worth it.

 Before optimization stats:

 * `check_url_config` took 67ms, or ~10% of the time for checks.
 * `LocaleRegexDescriptor.__get__()` showed 965 calls taking ~60ms, ~9% of
 the total runtime of checks.
 * `re.compile()` showed 741 calls for 94ms.
 * `_route_to_regex()` had 1900 calls taking 18ms (~2.6% of the total
 runtime).

 After optimization:

 * `check_url_config()` took 5ms, ~0.9% of the new total runtime.
 * The calls to `LocaleRegexDescriptor.__get__` are gone.
 * `re.compile()` drops to 212 calls from other sites, for a total of 51ms.
 * `_route_to_regex()` drops to the expected 950 calls, taking half the
 time at 9ms.

--
-- 
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] #35250: Stop URL system checks from compiling regular expressions

[Django]

#35250: Stop URL system checks from compiling regular expressions
-+-
   Reporter:  Adam   |  Owner:  Adam Johnson
  Johnson|
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Core   |Version:  dev
  (System checks)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Continuing my project to optimize the system checks, I found some good
 optimizations under  `django.core.checks.urls.check_url_config()`, which
 showed up as quite expensive in profiling.

 Looking down the call tree, it seems the most expensive part of this
 process is compiling the each URL pattern’s regular expression. This is
 unnecessary work though, as the checks only need *uncompiled* regular
 expression patterns. Using the compiled versions “undoes” the lazy-compile
 optimization that `LocaleRegexDescriptor` was created for in #27453 /
 6e222dae5636f875c19ec66f730a4241abe33faa, at least for any process that
 runs checks.

 The checks were fetching the uncompiled pattern with `self.regex.pattern`,
 which makse `LocaleRegexDescriptor`  compile the pattern only to then read
 the uncompiled pattern from
 [https://docs.python.org/3.12/library/re.html#re.Pattern.pattern its
 pattern attribute].

 Additionally, `RoutePattern` was calling `_route_to_regex()` twice to
 fetch its two result variables in different places: once in `__init__()`
 and again in `_compile()`. This function is non-trivial.

 Before optimization stats:

 * `check_url_config` took 67ms, or ~10% of the time for checks.
 * `LocaleRegexDescriptor.__get__()` showed 965 calls taking ~60ms, ~9% of
 the total runtime of checks.
 * `re.compile()` showed 741 calls for 94ms.
 * `_route_to_regex()` had 1900 calls taking 18ms (~2.6% of the total
 runtime).

 After optimization:

 * `check_url_config()` took 5ms, ~0.9% of the new total runtime.
 * The calls to `LocaleRegexDescriptor.__get__` are gone.
 * `re.compile()` drops to 212 calls from other sites, for a total of 51ms.
 * `_route_to_regex()` drops to the expected 950 calls, taking half the
 time at 9ms.
-- 
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/0107018ddc8c18bd-6ac395e6-aecc-4d5c-8a7e-c4566516a823-00%40eu-central-1.amazonses.com.

Re: [Django] #13033: MySQL full text search in admin

[Django]

#13033: MySQL full text search in admin
--+
 Reporter:  Simon Litchfield  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.admin |  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 Adam Zapletal):

 Replying to [comment:10 Sasha Gaevsky]:
 > This is already implemented -
 
https://github.com/django/django/blob/917cc288a38f3c114a5440f0749b7e5e1086eb36/django/contrib/admin/options.py#L888.
 >
 > I believe ticket could be closed.

 It looks like the `__search` lookup is only implemented for Postgres (in
 `contrib.postgres`):
 https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#std-
 fieldlookup-search

 There is currently no `contrib.mysql`. Is this level of MySQL-specific
 behavior of interest to Django?
-- 
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/0107018ddbcf749a-b56178a8-7611-4317-bb3b-7e0d3d9cc8b6-00%40eu-central-1.amazonses.com.

[Django] #35249: DISABLE_SERVER_SIDE_CURSORS is not documented as a connection setting

[Django]

#35249: DISABLE_SERVER_SIDE_CURSORS is not documented as a connection setting
--+
   Reporter:  Johannes Maron  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Documentation   |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   |
--+
 `DISABLE_SERVER_SIDE_CURSORS` is documented as a Django setting when it is
 in fact a connection setting.

 See also:

 https://docs.djangoproject.com/en/5.0/ref/settings/#disable-server-side-
 cursors
 
https://github.com/django/django/blob/6e1ece7ed522c904a674966fa985159b7bbf1545/django/db/models/query.py#L540-L542

 The correct usage is:


 {{{
 # settings.py

 DATABASES = {
 "default": {
 # …
 "DISABLE_SERVER_SIDE_CURSORS": True,
 },
 }
 }}}
-- 
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/0107018ddae42c21-86cb1128-d168-4e19-a30f-195d938c9efe-00%40eu-central-1.amazonses.com.