Re: [Django] #28628: Audit for and abolish all use of '\d' in regexes

[Django]

#28628: Audit for and abolish all use of '\d' in regexes
-+-
 Reporter:  James Bennett|Owner:  Ad
 Type:   |  Timmering
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  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 Ad Timmering):

 * 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/069.85d98797a0783a2fd063565ce7ff4bbb%40djangoproject.com.

Re: [Django] #33267: Add Hyperlink to related model in admin change form.

[Django]

#33267: Add Hyperlink to related model in admin change form.
+
 Reporter:  Thomas Güttler  |Owner:  Shubh Parmar
 Type:  New feature |   Status:  assigned
Component:  contrib.admin   |  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 Shubh Parmar):

 Do I have to provide a hyperlink to the related object's change page or to
 the related model's changelist page?

-- 
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/065.cc94c177732544580981ce9156f8ff32%40djangoproject.com.

Re: [Django] #31026: Switch form rendering to template engine

[Django]

#31026: Switch form rendering to template engine
-+-
 Reporter:  Johannes Maron   |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"03a648811615cb623affc2d79dccd4b05919319e" 03a64881]:
 {{{
 #!CommitTicketReference repository=""
 revision="03a648811615cb623affc2d79dccd4b05919319e"
 Refs #31026 -- Changed @jinja2_tests imports to be relative.
 }}}

-- 
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.fed2fd2d09b19560aa5139af556b9247%40djangoproject.com.

[Django] #33405: Documentation for template filter 'escapejs' is extremely unclear

[Django]

#33405: Documentation for template filter 'escapejs' is extremely unclear
-+
   Reporter:  Jon Ribbens|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  4.0
   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  |
-+
 The documentation says:

  Escapes characters for use in JavaScript strings. This does not make
 the string safe for use in HTML or JavaScript template literals, but does
 protect you from syntax errors when using templates to generate
 JavaScript/JSON.

 The first sentence is unclear - JavaScript strings ''where''? Inside `on`
 attributes? Inside `

Re: [Django] #33403: Annotate results change when filtering *after* the annotate

[Django]

#33403: Annotate results change when filtering *after* the annotate
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-

Comment (by karyon):

 I just realized there was an underscore missing in the original report: It
 should be "books__pages", and not "books_pages". Sorry for the confusion!

-- 
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.9fe1f933634e35485470429a4b331709%40djangoproject.com.

Re: [Django] #33403: Annotate results change when filtering *after* the annotate

[Django]

#33403: Annotate results change when filtering *after* the annotate
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-
Description changed by karyon:

Old description:

> Publisher A has two books with each 100 pages.
>

> {{{
> Publisher.objects.annotate(Sum("books_pages"))
> }}}
>
> will give you 200 as the sum. However, adding a filter after the annotate
>
> {{{
> Publisher.objects.annotate(Sum("books_pages")).filter(books__in=Books.objects.all())
> }}}
>
> will give you 400. (apparently that's the correct sum 200 multiplied by
> the number of books of that publisher)
>
> I understand that joins in annotates can produce incorrect results, akin
> to the one documented here:
> [https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#combining-
> multiple-aggregations #combining-multiple-aggregations]. However, the
> docs there say only "Combining multiple aggregations with annotate() will
> yield the wrong results", and here I'm not combining multiple
> aggregations. Furthermore,
> [https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#order-of-
> annotate-and-filter-clauses #order-of-annotate-and-filter-clauses] says
> "When an annotate() clause is applied to a query, the annotation is
> computed over the state of the query up to the point where the annotation
> is requested.", which further made me believe this should actually work.

New description:

 Publisher A has two books with each 100 pages.


 {{{
 Publisher.objects.annotate(Sum("books__pages"))
 }}}

 will give you 200 as the sum. However, adding a filter after the annotate

 {{{
 
Publisher.objects.annotate(Sum("books__pages")).filter(books__in=Books.objects.all())
 }}}

 will give you 400. (apparently that's the correct sum 200 multiplied by
 the number of books of that publisher)

 I understand that joins in annotates can produce incorrect results, akin
 to the one documented here:
 [https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#combining-
 multiple-aggregations #combining-multiple-aggregations]. However, the docs
 there say only "Combining multiple aggregations with annotate() will yield
 the wrong results", and here I'm not combining multiple aggregations.
 Furthermore, [https://docs.djangoproject.com/en/4.0/topics/db/aggregation
 /#order-of-annotate-and-filter-clauses #order-of-annotate-and-filter-
 clauses] says "When an annotate() clause is applied to a query, the
 annotation is computed over the state of the query up to the point where
 the annotation is requested.", which further made me believe this should
 actually 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/064.b128b5c0e24aa7fa05ace99f364c0b09%40djangoproject.com.

Re: [Django] #33403: Annotate results change when filtering *after* the annotate

[Django]

#33403: Annotate results change when filtering *after* the annotate
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-

Comment (by karyon):

 Hi Simon, I'm sorry if I was unclear. I didn't intend this to be a
 question, I already have a workaround in place. This was intended to be a
 bug report: Two sections/sentences in the documentation are incorrect as
 to which cases should or should not work, see the last paragraph of my
 report.

 In particular, I think the entire section "combining multiple
 aggregations" should be generalized, since it's not only a second
 annotation that triggers the issue, but (apparently?) any operation that
 produces another join, such as filtering by an attribute in a related
 model. In addition, the sentence "the annotation is computed over the
 state of the query up to the point where the annotation is requested" is
 misleading: A subsequent filter or additional aggregation can alter the
 results of a previous one. It could help users if we added something like
 "except for these cases ".

 Your suggested solution is not necessary in this case, simply filtering
 before the annotation does work correctly as far as I could see:

 {{{
 # works as expected, sums the filtered books
 
Publisher.objects.filter(books__in=Books.objects.all()).annotate(Sum("books_pages"))
 }}}

 What does not work correctly is filtering the publishers by some property
 of their books *after* the aggregation without affecting the aggregation:

 {{{
 # this alters the sum although the documentation suggests this should just
 work
 
Publisher.objects.annotate(Sum("books_pages")).filter(books__in=Books.objects.all())
 }}}

-- 
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.97f063f361ff9de4f2560053ac20e16f%40djangoproject.com.

Re: [Django] #28949: Multibyte table name or column name causes miscalculation of the length of index name.

[Django]

#28949: Multibyte table name or column name causes miscalculation of the length 
of
index name.
-+-
 Reporter:  Pak Youngrok |Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  migration multibyte  | Triage Stage:  Accepted
  index  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * owner:  (none) => Jacob Walls
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15273 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/066.703cb7b747100ab1ed5cf770e85e7339%40djangoproject.com.

Re: [Django] #33402: Optimize multiple AlterFooTogether operations into one

[Django]

#33402: Optimize multiple AlterFooTogether operations into one
-+-
 Reporter:  David Wobrock|Owner:  David
 Type:   |  Wobrock
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  alteruniquetogether  | Triage Stage:  Accepted
  alterindextogether migration   |
  optimizer  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * 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/071.e2ffe02b32194d03f3b4b3ccd430be3a%40djangoproject.com.

Re: [Django] #27844: Add a management command to optimize a migration

[Django]

#27844: Add a management command to optimize a migration
-+-
 Reporter:  Raphael Gaschignard  |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):

 * cc: David Wobrock (added)
 * needs_docs:  1 => 0
 * owner:  nobody => David Wobrock
 * needs_tests:  1 => 0


Comment:

 Hi there,

 Reviving this ticket, I think this command could be quite useful,
 especially when you upgrade Django on older projects, and new migration
 optimizations were added since.

 I submitted a PR inspired by the attached patch.
 [https://github.com/django/django/pull/15272 PR]

 I made a quite specific choice for the logic of the command. By default,
 it overwrites the named migration. But if some manual porting is required,
 it will rather try to create a replacement migration. My thought was that,
 if functions need manual porting, we don't want to lose the code by
 overwriting the migration file.
 Tell me what you think of this :)

-- 
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.c1b54e60e42c6fc72252d1686302c927%40djangoproject.com.