Re: [Django] #33005: Django is saving redundant or empty data in the SQLite database

[Django]

#33005: Django is saving redundant or empty data in the SQLite database
-+-
 Reporter:  Palash Vishnani  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid
 * easy:  1 => 0


Comment:

 Thanks for the report, however it looks like an issue in your code, not in
 Django itself. Please reopen the ticket if you can debug your issue and
 provide details about why and where Django is at fault. If you're having
 trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

-- 
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/073.c7748fcd06402b2eb5a500d33f532913%40djangoproject.com.

Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
--+
 Reporter:  mrts  |Owner:  mrts
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * needs_tests:  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/062.a8af1b9ac03628a5b7b0370d12491cab%40djangoproject.com.

[Django] #33005: Django is saving redundant or empty data in the SQLite database

[Django]

#33005: Django is saving redundant or empty data in the SQLite database
-+-
   Reporter:  Palash-|  Owner:  nobody
  Vishnani   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I am using an HTML form to save my data into the database, the data
 entries are stored correctly but some cache entries are also stored along
 with them. Why is that so?
 [[Image(https://user-
 images.githubusercontent.com/81798761/128661933-02be6181-9bc5-4921-a2bf-
 864f1f8ed9e3.png)]]

-- 
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/058.739570ae867e235312786018c04e264e%40djangoproject.com.

Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
--+
 Reporter:  mrts  |Owner:  mrts
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * type:  New feature => Cleanup/optimization


-- 
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/062.b1a15d0b765c78e1bba49105dfcf0d20%40djangoproject.com.

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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 Chris Jerdonek):

 * 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/067.53a94960759a1c8eb55804cf3f042df1%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

[Django]

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Felix
 Type:   |  Zhang
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Felix Zhang):

 * has_patch:  0 => 1


Old description:

> While using Django REST Framework's Schema generator, I found out they're
> using `simplify_regex()`; however, current version has a few
> shortcomings, namely non-capturing groups are broken.

New description:

 While using Django REST Framework's Schema generator, I found out they're
 using `simplify_regex()`; however, current version has a few shortcomings,
 namely non-capturing groups are broken.

 I have opened a [https://github.com/django/django/pull/14756 pull request]
 that allows `simplify_regex()` to handle non-capturing groups and
 additional tests for them in `test_simplify_regex()`.

--

-- 
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/064.991c9adaaa3a39b1d1b0a91a5cc590e8%40djangoproject.com.

Re: [Django] #33003: Micro-optimisation for QuerySet._chain

[Django]

#33003: Micro-optimisation for QuerySet._chain
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  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 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/067.b0deec2b65ae4f89d91926d7563b6577%40djangoproject.com.

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 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 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/067.9c5b483488d4e0e0121a639dbdee3387%40djangoproject.com.

Re: [Django] #32995: Incorrect GROUP BY in ORM query with Function

[Django]

#32995: Incorrect GROUP BY in ORM query with Function
-+-
 Reporter:  Joshua "jag" |Owner:  nobody
  Ginsberg   |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (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:

 Thanks for extra details.

 > This feels like a bug, though not the one I originally believed.
 Thoughts?

 It's a duplicate of #32546 (fixed in Django 4.0).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4b76adaa675caa2dd65b2efe1e0830da%40djangoproject.com.

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * needs_better_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/067.e52b61eb8a0a87f2e4e56741f25d21be%40djangoproject.com.

[Django] #33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic Foreign Key

[Django]

#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
   Reporter: |  Owner:  nobody
  Finndersen |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|   Keywords:  fk, gfk, generic
   Severity:  Normal |  foreign key, validation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 https://code.djangoproject.com/ticket/10811 addresses the issue of
 assigned an unsaved model to a ForeignKey or OneToOneField (raises error
 when save() called), however the same logic / pattern does not apply to
 GFKs.

 Given:

 {{{#!python
 class ModelA(models.Model):
 name = models.CharField(max_length=20)


 class ModelB(models.Model):
 gfk_ctype = models.ForeignKey(ContentType, on_delete=models.PROTECT)
 gfk_id = models.PositiveIntegerField()
 gfk = GenericForeignKey('gfk_ctype', 'gfk_id')


 class ModelC(models.Model):
 fk = models.ForeignKey(ModelA, on_delete=models.CASCADE)
 }}}


 Foreign Key Behaviour:

 {{{
 In [2]: a = ModelA(name='Model A')

 In [3]: c = ModelC(fk=a)

 In [4]: c.fk
 Out[4]: 

 In [5]: c.save()
 ---
 ...
 ValueError: save() prohibited to prevent data loss due to unsaved related
 object 'fk'.

 In [6]: a.save()
 (0.016) INSERT INTO "test_app_modela" ("name") VALUES ('Model A');
 args=['Model A']

 In [7]: c.fk
 Out[7]: 

 In [8]: c.save()
 (0.016) INSERT INTO "test_app_modelc" ("fk_id") VALUES (1); args=[1]
 }}}

 GFK behaviour:



 {{{
 In [9]: a2 = ModelA(name='Model A2')

 In [10]: b = ModelB(gfk=a2)

 In [11]: b.gfk
 Out[11]: 

 In [12]: b.save()
 (0.000) INSERT INTO "test_app_modelb" ("gfk_ctype_id", "gfk_id") VALUES
 (9, NULL); args=[9, None]
 ---
 IntegrityError: NOT NULL constraint failed: test_app_modelb.gfk_id

 In [14]: b.gfk.save()
 (0.015) INSERT INTO "test_app_modela" ("name") VALUES ('Model A2');
 args=['Model A2']

 In [15]: b.gfk
 (0.000) SELECT "test_app_modela"."id", "test_app_modela"."name" FROM
 "test_app_modela" WHERE "test_app_modela"."id" IS NULL LIMIT 21; args=()
 None

 In [17]: b.gfk_ctype
 Out[17]: 
 }}}

 Two observations:
 * No check on b.gfk and b.gfk_id value during save() which could lead to
 silent data loss if b.gfk_id is nullable.
 * When a2 is saved, accessing b.gfk now does a redundant DB query to try
 and find ModelA instance with PK = None, then then returns None value
 (effectively un-assigning a2 model), while keeping b.gfk_ctype intact.
 This is because the new pk of a2 is different to the existing gfk_id
 (pk_val) of the GFK field (None)

 What should be done:
 * Modify Model.save() or Model._prepare_related_fields_for_save() to also
 perform verification check for GFK fields
 * Modify GenericForeignKey.__get__() to handle case of pk_val = None
 (update fk_field value using PK value of GFK model if present, do not
 perform redundant DB query on pk=None, return previously assigned (then
 saved) model instead of None)

-- 
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/053.8deb458a1d22243c93cb974224d2f420%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

[Django]

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Felix
 Type:   |  Zhang
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 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
-+-
Changes (by Felix Zhang):

 * owner:  nobody => Felix Zhang
 * status:  new => assigned


Old description:

> While using Django REST Framework's Schema generator, I found out they're
> using `simplify_regex()`; however, current version has a few
> shortcomings, namely non-capturing groups are broken.
>
> I added a pull request (see https://github.com/django/django/pull/8414)
> which fixes this problems, it also is faster and handles many more regex
> patterns. I also extended the `test_simplify_regex` test.

New description:

 While using Django REST Framework's Schema generator, I found out they're
 using `simplify_regex()`; however, current version has a few shortcomings,
 namely non-capturing groups are broken.

--

-- 
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/064.a499085ffa2ce64143d81e1b4326307a%40djangoproject.com.

Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
---+
 Reporter:  mrts   |Owner:  mrts
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Description changed by mrts:

Old description:

> Adding data attributes to items in ordinary non-autocomplete foreign key
> fields that use {{{forms.widgets.Select}}}-based widgets is relatively
> easy. This enables powerful and dynamic admin site customizations where
> fields from related models are updated immediately when users change the
> selected item.
>
> However, adding new attributes to autocomplete field results currently
> requires extending
> {{{contrib.admin.views.autocomplete.AutocompleteJsonView}}} and fully
> overriding the {{{AutocompleteJsonView.get()}}} method. Here's an
> example:
>
> {{{#!python
> class MyModelAdmin(admin.ModelAdmin):
> def get_urls(self):
> return [
> path('autocomplete/',
> CustomAutocompleteJsonView.as_view(admin_site=self.admin_site))
> if url.pattern.match('autocomplete/')
> else url for url in super().get_urls()
> ]
>
> class CustomAutocompleteJsonView(AutocompleteJsonView):
>
> def get(self, request, *args, **kwargs):
> self.term, self.model_admin, self.source_field, to_field_name =
> self.process_request(request)
>
> if not self.has_perm(request):
> raise PermissionDenied
>
> self.object_list = self.get_queryset()
> context = self.get_context_data()
> return JsonResponse({
> 'results': [
> {'id': str(getattr(obj, to_field_name)), 'text':
> str(obj), 'notes': obj.notes} # <-- customization here
> for obj in context['object_list']
> ],
> 'pagination': {'more': context['page_obj'].has_next()},
> })
> }}}
>

> The problem with this is that as {{{AutocompleteJsonView.get()}}} keeps
> evolving, there's quite a lot of maintenance overhead required to catch
> up.
>
> The solutions is simple, side-effect- and risk-free: adding a result
> customization extension point to {{{get()}}} by moving the lines that
> construct the results inside {{{JsonResponse}}} constructor to a separate
> method. So instead of
>
> {{{#!python
> return JsonResponse({
> 'results': [
> {'id': str(getattr(obj, to_field_name)), 'text':
> str(obj)}
> for obj in context['object_list']
> ],
> 'pagination': {'more': context['page_obj'].has_next()},
> })
> }}}
>
> there would be
>
> {{{#!python
> return JsonResponse({
> 'results': [
> self.obj_to_dict(obj, to_field_name) for obj in
> context['object_list']
> ],
> 'pagination': {'more': context['page_obj'].has_next()},
> })
> }}}
>
> where {{{obj_to_dict()}}} contains the original object to dictionary
> conversion code that would be now easy to override:
>
> {{{#!python
> def obj_to_dict(self, obj, to_field_name):
> return {'id': str(getattr(obj, to_field_name)), 'text': str(obj)}
> }}}
>
> The example {{{CustomAutocompleteJsonView}}} from above would now become
> succinct and maintainable:
>
> {{{#!python
> class CustomAutocompleteJsonView(AutocompleteJsonView):
>
> def obj_to_dict(self, obj, to_field_name):
> return super.obj_to_dict(obj, to_field_name) | {'notes':
> obj.notes}
> }}}
>
> What do you think, is this acceptable? I'm more than happy to provide the
> patch.

New description:

 Adding data attributes to items in ordinary non-autocomplete foreign key
 fields that use {{{forms.widgets.Select}}}-based widgets is relatively
 easy. This enables powerful and dynamic admin site customizations where
 fields from related models are updated immediately when users change the
 selected item.

 However, adding new attributes to autocomplete field results currently
 requires extending
 {{{contrib.admin.views.autocomplete.AutocompleteJsonView}}} and fully
 overriding the {{{AutocompleteJsonView.get()}}} method. Here's an example:

 {{{#!python
 class MyModelAdmin(admin.ModelAdmin):
 def get_urls(self):
 return [
 path('autocomplete/',
 CustomAutocompleteJsonView.as_view(admin_site=self.admin_site))
 if url.pattern.match('autocomplete/')
 else url for url in super().get_urls()
 ]

 class 

Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
---+
 Reporter:  mrts   |Owner:  mrts
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by mrts):

 Thanks for the heads up! Will keep it in mind in the future.

-- 
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/062.7151929f59b6de4d4e97f978e055e629%40djangoproject.com.

Re: [Django] #33003: Micro-optimisation for QuerySet._chain

[Django]

#33003: Micro-optimisation for QuerySet._chain
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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
-+-
Changes (by Keryn Knight):

 * has_patch:  0 => 1


Comment:

 PR is https://github.com/django/django/pull/14755. CI is still running
 atm. Probably makes sense for someone to check the timings are
 independently repeatable given the timescales in question (`ns`). Python
 version used was `3.9.5`.

-- 
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/067.634ccae5c5501620673b1e7572236d8d%40djangoproject.com.

[Django] #33003: Micro-optimisation for QuerySet._chain

[Django]

#33003: Micro-optimisation for QuerySet._chain
-+-
   Reporter:  Keryn  |  Owner:  Keryn Knight
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  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  |
-+-
 Whilst working on #28455 I noticed that `_chain` accepts `kwargs`, but
 that appears to only be to facilitate pickling, with
 `Prefetch.__getstate__` making use of the functionality. Thus most of the
 time, kwargs is empty and there's no reason to touch/update the
 `__dict__`. And it's faster not to do so. Note that in comparison with the
 benefits of #28455 this is absolutely peanuts, but still, it's unrelated
 to that ticket so here we are:

 {{{
 In [1]: class A:
...: def __init__(self, **kwargs):
...: self.__dict__.update(**kwargs)
 In [2]: a = A(a=1, b=2, c=3, d=4)
 In [3]: empty = {}
 In [4]: full = {'d': 3, 'c': 1}
 In [5]: %timeit a.__dict__.update(empty)
 91.2 ns ± 1.25 ns per loop (mean ± std. dev. of 7 runs, 1000 loops
 each)
 In [6]: %timeit a.__dict__.update(full)
 133 ns ± 0.92 ns per loop (mean ± std. dev. of 7 runs, 1000 loops
 each)
 }}}
 If we just ''check'' the dictionary isn't empty (in `_chain` that's
 `kwargs`):
 {{{
 In [7]: %timeit if empty: a.__dict__.update(empty)
 19 ns ± 0.377 ns per loop (mean ± std. dev. of 7 runs, 1000 loops
 each)
 In [8]: %timeit if full: a.__dict__.update(full)
 156 ns ± 1.33 ns per loop (mean ± std. dev. of 7 runs, 1000 loops
 each)
 }}}

 You can see the paying the basic cost of an if (for me, that appears to be
 `20ns` for an empty dict, and more like `6ns` for an interned/singleton
 value like `1` or `True` or `''` as a baseline) is worthwhile, and having
 pickling a Prefetch be `20ns` slower isn't too bad, given it's not exactly
 the most common use case...

 The difference is small but can be made more obvious by checking the
 cProfile timings over many (''many'') iterations; here's the before across
 100 users each with a group and permission:
 {{{
 In [2]: %prun -stime -l_chain for _ in range(1000):
 tuple(User.objects.prefetch_related('groups', 'user_permissions',
 'groups__permissions'))
 48095003 function calls (46202003 primitive calls) in 34.811 seconds

 Ordered by: internal time
 List reduced from 384 to 1 due to restriction <'_chain'>

 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 3120004.0700.0008.7910.000 query.py:1325(_chain)
 In [3]: %timeit -n1000 -r10 tuple(User.objects.prefetch_related('groups',
 'user_permissions', 'groups__permissions'))
 18.3 ms ± 391 µs per loop (mean ± std. dev. of 10 runs, 100 loops each)
 }}}
 And after applying the change as follows:
 {{{
 def _chain(...):
 ...
 if kwargs:
 obj.__dict__.update(kwargs)
 ...
 }}}
 we end up with:
 {{{
 In [2]: %prun -stime -l_chain for _ in range(1000):
 tuple(User.objects.prefetch_related('groups', 'user_permissions',
 'groups__permissions'))
 47779003 function calls (45886003 primitive calls) in 33.220 seconds

 Ordered by: internal time
 List reduced from 384 to 1 due to restriction <'_chain'>

 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 3120000.2670.0005.6440.000 query.py:1325(_chain)
 In [3]: %timeit -n1000 -r10 tuple(User.objects.prefetch_related('groups',
 'user_permissions', 'groups__permissions'))
 18.1 ms ± 289 µs per loop (mean ± std. dev. of 10 runs, 100 loops each)
 }}}

 I have to assume that the overall timing differences measured by cProfile
 and timeit are both just standard fluctuations, despite cProfile's
 `tottime` reporting there.

 Branch/PR to follow. It won't be a shock if the diff is 3 lines long,
 given the change is shown above.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.9e039a6558d8e5ef01abdf9b7476a453%40djangoproject.com.

Re: [Django] #29470: Add output to makemigrations and migrate commands with --noinput

[Django]

#29470: Add output to makemigrations and migrate commands with --noinput
--+--
 Reporter:  Kurt Wheeler  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Migrations|  Version:  1.11
 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
--+--

Comment (by Chris Jerdonek):

 From a discussion in a [https://github.com/django/django/pull/14751 PR]
 for #29026, I think this ticket should be re-opened and handled separately
 from #29026. My suggestion for addressing this would be to modify the non-
 interactive questioner so that it logs non-empty output when a question is
 asked (e.g. saying "Such-and-such question was answered automatically with
 ..."). This could / should be done using the same output method that the
 migration command class is using for its logging output.

-- 
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/069.fe532ecd3a2349ba71df3c60ae36baf4%40djangoproject.com.

Re: [Django] #32994: Invoking runtests with a CLI prelude causes utils_tests failures

[Django]

#32994: Invoking runtests with a CLI prelude causes utils_tests failures
-+-
 Reporter:  Keryn Knight |Owner:  Jonny
 Type:   |  Park
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  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 Jonny Park):

 * owner:  nobody => Jonny Park
 * status:  new => assigned


-- 
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/067.7d93c0889f3cd882a4652b0e04f99b6c%40djangoproject.com.