Re: [Django] #25255: Squashed migration is not marked as unapplied

[Django]

#25255: Squashed migration is not marked as unapplied
-+-
 Reporter:  Markus Holtermann|Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 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
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

Re: [Django] #31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT

[Django]

#31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE
CONSTRAINT
-+-
 Reporter:  Adam Johnson |Owner:  Sanskar
 |  Jaiswal
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  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
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"8c3bd0b708b488a1f6e8bd8cc6b96569904605be" 8c3bd0b7]:
 {{{
 #!CommitTicketReference repository=""
 revision="8c3bd0b708b488a1f6e8bd8cc6b96569904605be"
 Fixed #31653 -- Added AddConstraintNotValid()/ValidateConstraint()
 operations for PostgreSQL.
 }}}

-- 
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/068.0b1420be11d223b3e690f4c30f13a877%40djangoproject.com.

Re: [Django] #32813: Display development server address after server bind

[Django]

#32813: Display development server address after server bind
-+-
 Reporter:  fmwviormv|Owner:  fmwviormv
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  development server,  | Triage Stage:  Accepted
  automatic port |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * type:  New feature => Bug
 * 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.5d271e3a595fcfe68e546d0c603bc0b1%40djangoproject.com.

Re: [Django] #32827: Squashing migrations isn't very effective in complicated projects; rewrite docs to provide a preferred manual trimming process

[Django]

#32827: Squashing migrations isn't very effective in complicated projects; 
rewrite
docs to provide a preferred manual trimming process
-+-
 Reporter:  Mike Lissner |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  migrations,  | Triage Stage:  Accepted
  squashmigration, documentation |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, happy to review a suggestion.Thanks.

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

Re: [Django] #25255: Squashed migration is not marked as unapplied

[Django]

#25255: Squashed migration is not marked as unapplied
---+---
 Reporter:  Markus Holtermann  |Owner:  Jacob Walls
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  1.8
 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 Jacob Walls):

 * owner:  nobody => Jacob Walls
 * needs_better_patch:  1 => 0
 * status:  new => assigned


Comment:

 [https://github.com/django/django/pull/14500 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/065.85b0fdbaa1c57d99475390dff82e9d55%40djangoproject.com.

Re: [Django] #32801: Support for non-aggregation subqueries in FROM clause

[Django]

#32801: Support for non-aggregation subqueries in FROM clause
-+-
 Reporter:  Jameel A.|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 Thanks for the detailed report. I agree that this is a duplicate of
 #24462, that could also be solved by #28919 (CTE).

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

Re: [Django] #32824: Potential micro-optimisations for NodeList.render

[Django]

#32824: Potential micro-optimisations for NodeList.render
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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 Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 We don't even need `bits`, so maybe:
 {{{
 def render(self, context):
 return SafeString(''.join([
 str(node.render_annotated(context))
 for node in self
 ]))
 }}}

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

Re: [Django] #32826: Allow for custom groupings in Django Admin

[Django]

#32826: Allow for custom groupings in Django Admin
---+--
 Reporter:  Karim Ouada|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  admin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * has_patch:  1 => 0
 * resolution:   => duplicate


Comment:

 Duplicate of #7497 (see also
 [https://code.djangoproject.com/ticket/11895#comment:3 comment]).

-- 
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/068.d4780448d584138033062fa2216f7dbd%40djangoproject.com.

[Django] #32827: Squashing migrations isn't very effective in complicated projects; rewrite docs to provide a preferred manual trimming process

[Django]

#32827: Squashing migrations isn't very effective in complicated projects; 
rewrite
docs to provide a preferred manual trimming process
-+-
   Reporter:  Mike   |  Owner:  nobody
  Lissner|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|   Keywords:  migrations,
   Severity:  Normal |  squashmigration, documentation
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm creating this ticket as a tracker, having already discussed this
 briefly on the mailing list:

 https://groups.google.com/g/django-developers/c/xpeFRpMTBZw/m/lDq78EedAwAJ

 and having already created a PR for this:

 https://github.com/django/django/pull/14408

 My impression is that to get this back on the review queue I need 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/051.b778b90645c78b5852ce28f4c0748439%40djangoproject.com.

Re: [Django] #32825: Django unit tests with postgres can take an exceeding long time

[Django]

#32825: Django unit tests with postgres can take an exceeding long time
--+--
 Reporter:  Rich Rauenzahn|Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  2.2
 Severity:  Normal|   Resolution:  needsinfo
 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):

 * resolution:  invalid => needsinfo


Comment:

 > Autovacuum is the default in postgres already -- suggesting to turn it
 on is not a helpful suggestion.

 I don't know your database configurations and assumed that if `VACUUM`
 helps in your case then maybe it's turn off.

 > I don't feel like you're really understanding the issue as I've reported
 it. Let me know if there is anything I can do to further clarify.

 You've not explained the issue in enough detail to confirm a bug in
 Django. Please reopen the ticket if you can debug your issue and provide
 details about why and where Django is at fault.

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

[Django] #32826: Allow for custom groupings in Django Admin

[Django]

#32826: Allow for custom groupings in Django Admin
-+
   Reporter:  Karim Ouada|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  3.2
   Severity:  Normal |   Keywords:  admin
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+
 I recently stumbled upon a small issue in my Django project and thought it
 might be something that could be helpful for other people as well.

 I had a Django app and registered my entities in the Django admin. I
 didn't like the fact that they were all grouped together, so I wanted to
 separate them into different subcategories. Obviously Django groups those
 entities by `app_name`, which I didn't want to change in the models since
 many things rely on it. So instead I decided to extend the
 `_build_app_dict` method in AdminSite to allow for a custom name, as it
 seems that the `app_dict` created in that method is only a representation
 for the UI in the Django admin.

 The way it would work is that there is a new optional parameter in the
 `admin.ModelAdmin` called `group_name` and you can specify a
 group/category that the entities in the Django admin will be grouped in.
 If you don't specify it then the default is just the `app_label`.

 I would definitely love to contribute back to Django with this small
 improvement and I know there are quite some threads online where people
 were looking for such behavior. Let me know if you think that makes sense
 and could be helpful.

 I already created a small PR with a sample implementation:
 https://github.com/ouadakarim/django/pull/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/053.db53374eaa26cdbb0ff08886202a5c0a%40djangoproject.com.

Re: [Django] #29865: Add XOR for use in Q Queries

[Django]

#29865: Add XOR for use in Q Queries
-+-
 Reporter:  Griffith Rees|Owner:  Ryan
 |  Heard
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  xor  | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ryan Heard):

 After careful consideration I have decided not to raise a `TypeError` on
 unsupported backends, and instead convert on the fly from `A XOR B` to `(A
 OR B) AND NOT (A AND B)`.

 MySQL will still take advantage of logical XOR.

-- 
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/063.44344f03e17402fce233fc211b3fb515%40djangoproject.com.

Re: [Django] #32825: Django unit tests with postgres can take an exceeding long time

[Django]

#32825: Django unit tests with postgres can take an exceeding long time
--+--
 Reporter:  Rich Rauenzahn|Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  2.2
 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 Rich Rauenzahn):

 Autovacuum is the default in postgres already -- suggesting to turn it on
 is not a helpful suggestion.  I don't feel like you're really
 understanding the issue as I've reported it.  Let me know if there is
 anything I can do to further clarify.

 This is more of an integration issue between the two than a bug in Django.
 Transactional unit tests apparently can cause degenerate query cases in
 postgres (at least 11) even though the db is a freshly created db every
 test run.

 Regardless, I think the only action is to give a heads up to the relevant
 django devs in case they see something else like it in the future.  It has
 taken me days to troubleshoot and I'd like to prevent anyone else having
 to go through this debug process.

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

Re: [Django] #32814: Improve performance of TextNode rendering by providing a special-case of render_annotated

[Django]

#32814: Improve performance of TextNode rendering by providing a special-case of
render_annotated
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 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 GitHub ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"7f6a41d3d915feb01acfa08b2b936d1199db3ba6" 7f6a41d]:
 {{{
 #!CommitTicketReference repository=""
 revision="7f6a41d3d915feb01acfa08b2b936d1199db3ba6"
 Fixed #32814 -- Improved performance of TextNode.

 This avoids calling render() and handling exceptions, which is not
 necessary for text nodes.
 }}}

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

Re: [Django] #32825: Django unit tests with postgres can take an exceeding long time

[Django]

#32825: Django unit tests with postgres can take an exceeding long time
--+--
 Reporter:  Rich Rauenzahn|Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  2.2
 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


Comment:

 I don't think it's a bug in Django. Please reopen the ticket if you can
 debug your issue and provide details about why and where Django is at
 fault. Also, you should be able to enable
 [https://www.postgresql.org/docs/13/runtime-config-autovacuum.html
 Automatic Vacuuming] on your database.

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

Re: [Django] #32824: Potential micro-optimisations for NodeList.render

[Django]

#32824: Potential micro-optimisations for NodeList.render
-+-
 Reporter:  Keryn Knight |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  dev
 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
-+-

Comment (by Jacob Walls):

 Tim McCurrach proposed directly returning `SafeString` in several places
 in #32568.

 Regarding the rest of the proposal, `NodeList` is documented to consist of
 `Node` objects, so option #2 sounds right-track to me:
 {{{
 ``parser.parse()`` takes a tuple of names of block tags ''to parse
 until''. It
 returns an instance of ``django.template.NodeList``, which is a list of
 all ``Node`` objects that the parser encountered ''before'' it encountered
 any of the tags named in the tuple.
 }}}

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

[Django] #32825: Django unit tests with postgres can take an exceeding long time

[Django]

#32825: Django unit tests with postgres can take an exceeding long time
+
   Reporter:  Rich Rauenzahn|  Owner:  (none)
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  2.2
   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 |
+
 I've had this happen with two different projects now and both I was able
 to resolve with the same "hack".

 I don't completely understand the actual mechanism for the degenerate case
 (I do have some explain plans I can share, but I'm not sure is relevant
 given my solution).

 This was reproducible in my environment repeatedly: some queries in
 postgres during unit tests hit a degenerate case (with relatively small
 amounts of data!) where they take 100 of times longer than normal
 (production seems fine.)  I'm talking about 2.5 minute queries that takes
 seconds normally.

 postgresql11-server-11.12-1PGDG.rhel7.x86_64

 The solution in both projects is the following mixin I add to my test case
 classes:

 {{{
 def _vacuum():
 # Some unit test queries seem to take a much longer time.
 # Let's try vacuuming.
 # https://stackoverflow.com/a/13955271/2077386
 with connection.cursor() as cursor:
 logging.info("Vacuum: begin")
 cursor.execute("VACUUM ANALYZE")
 logging.info("Vacuum: complete")

 class VacuumMixin:
 @classmethod
 def setUpClass(cls):
 _vacuum()
 return super().setUpClass()

 @classmethod
 def tearDownClass(cls):
 ret = super().tearDownClass()
 _vacuum()
 return ret
 }}}

 I realize this is more of a postgres problem than a Django problem, but I
 wanted to raise awareness of it in case people have similar problem.  I'm
 not sure its practical to run vacuum in the underlying Django code given
 that there may be more than one database, etc.?

-- 
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/051.1367466c72ac7574cc2a36b9b383256a%40djangoproject.com.

Re: [Django] #32824: Potential micro-optimisations for NodeList.render

[Django]

#32824: Potential micro-optimisations for NodeList.render
-+-
 Reporter:  Keryn Knight |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  dev
 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
-+-
Changes (by Keryn Knight):

 * Attachment "textnode_test2.py" added.

 yappi/cprofile/timeit oriented template rendering (1 complex template,
 fake/minimal context)

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

[Django] #32824: Potential micro-optimisations for NodeList.render

[Django]

#32824: Potential micro-optimisations for NodeList.render
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Template system   |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 |
+
 The current implementation of `NodeList.render` looks like:
 {{{
 def render(self, context):
 bits = []
 for node in self:
 if isinstance(node, Node):
 bit = node.render_annotated(context)
 else:
 bit = node
 bits.append(str(bit))
 return mark_safe(''.join(bits))
 }}}

 which, given a single template render (template + code to be attached, but
 is basically the same fakery as in #32814) is rendered 41 times (cProfile
 output, relevant portions to be discussed in this ticket only):
 {{{
41/10.0000.0000.0070.007 base.py:956(render)
 5910.0000.0000.0000.000 {built-in method
 builtins.hasattr}
 1910.0000.0000.0000.000 {built-in method
 builtins.callable}
 115/1130.0000.0000.0000.000 safestring.py:53(mark_safe)
 }}}

 Given the numbers are too miniscule to register, for the purposes of
 surfacing the most time consuming parts, and pushing things like importlib
 machinery etc to the bottom of the profile output, rendering the same
 template 1000 times gives us:
 {{{
 4897753 function calls (4539046 primitive calls) in 2.832 seconds

  41000/10000.1930.0002.6710.003 base.py:956(render)
 70045/680450.0420.0000.0950.000
 safestring.py:50(mark_safe)
  1280450.0530.0000.0530.000 safestring.py:26(__init__)
  1594320.0230.0000.0230.000 {built-in method
 builtins.hasattr}
  1140770.0120.0000.0120.000 {built-in method
 builtins.callable}
  6865820.0760.0000.0760.000 {built-in method
 builtins.isinstance}
  3181840.0360.0000.0360.000 {method 'append' of 'list'
 objects}
 }}}
 (to ensure `SafeString.__init__` calls are registered, I manually created
 the method, so timings for it aren't correct but counts will be).

  Proposed change

 The primary change I'm suggesting is deviating from using `mark_safe` to
 directly returning a new `SafeString` - as far as I know, the result of
 `''.join(...)` is ''always'' of type `str` regardless of if any of the
 underlying bits are themselves `SafeString` etc, so for each call to
 `NodeList.render` we'd be saving 1 `hasattr(...)` test and 1
 `callable(...)` test, which would change the 1000 runs to:
 {{{
 4774747 function calls (4416040 primitive calls) in 2.710 seconds

  41000/10000.1940.0002.6690.003 base.py:956(render)
 29045/270450.0190.0000.0630.000
 safestring.py:50(mark_safe)
  1280450.0480.0000.0480.000 safestring.py:26(__init__)
  1184320.0190.0000.0190.000 {built-in method
 builtins.hasattr}
   730770.0080.0000.0080.000 {built-in method
 builtins.callable}
  6865820.0730.0000.0730.000 {built-in method
 builtins.isinstance}
  3181840.0380.0000.0380.000 {method 'append' of 'list'
 objects}
 }}}

 You can see that whilst the timings don't change ''substantially'', it is
 a whole bunch less calls.

  Worth investigating?

 But ''possibly'' more interesting than that is the rest of the method. As
 far as I can tell from running the test suite (which, tbf, does include a
 boatload of skips being output), the line `if isinstance(node, Node):` is
 **always** true -- that is, there's no test anywhere for what happens if
 you somehow, somewhere include a non `Node` instance into a `NodeList`? If
 that's the case (which again, it may not be, given skips) then there's 2
 possiblities:

 1. add in a test demonstrating what should happen when a `non-Node`
 appears in a `NodeList` and canonically accept it as part of DTL
 2. take the stance that NodeLists are inherently composed of only nodes
 (or at least things with `render_annotated(context)`) and sweep away the
 isinstance check.

 If option 2 were taken, the final method could be (without any
 intermediate deprecation stuffs if necessary):
 {{{
 def render(self, context):
 bits = []
 append = bits.append
 for node in self:
 append(str(node.render_annotated(context)))
 return SafeString(''.join(bits))
 }}}

 which, compounded with the change from `mark_safe` to `SafeString`
 prop

Re: [Django] #31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT

[Django]

#31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE
CONSTRAINT
-+-
 Reporter:  Adam Johnson |Owner:  Sanskar
 |  Jaiswal
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 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
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


-- 
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/068.293ba9d75fe5df7cb2ca51ab1ac7f2ff%40djangoproject.com.

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 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):

 * status:  assigned => closed
 * resolution:   => fixed


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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e96e93618c608a422a6fee81de2f932ca3094d81" e96e936]:
 {{{
 #!CommitTicketReference repository=""
 revision="e96e93618c608a422a6fee81de2f932ca3094d81"
 Refs #32668 -- Passed setup()'s return value to run_tests() instead of
 get_installed().
 }}}

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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"b3083d5bd244ca90848aaa2a1c8e7ba7f9cc72f4" b3083d5b]:
 {{{
 #!CommitTicketReference repository=""
 revision="b3083d5bd244ca90848aaa2a1c8e7ba7f9cc72f4"
 Refs #32668 -- Refactored out setup_collect_tests() in runtests.py.
 }}}

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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9389d4d3dbfed050045d514c19bc11680f67c6d6" 9389d4d3]:
 {{{
 #!CommitTicketReference repository=""
 revision="9389d4d3dbfed050045d514c19bc11680f67c6d6"
 Refs #32668 -- Changed bisect_tests() and paired_tests() to use only
 setup_collect_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/067.a0f61e2966f103491a91c383d50cd82e%40djangoproject.com.

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"87bb746ea6bb4bf6fb9f87065d5daaca857a130c" 87bb746e]:
 {{{
 #!CommitTicketReference repository=""
 revision="87bb746ea6bb4bf6fb9f87065d5daaca857a130c"
 Refs #32668 -- Renamed setup()/teardown() to
 setup_run_tests()/teardown_run_tests() in runtests.py.
 }}}

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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9b9cea04b98b66a68b7588cc4c34401f5f7d7c12" 9b9cea04]:
 {{{
 #!CommitTicketReference repository=""
 revision="9b9cea04b98b66a68b7588cc4c34401f5f7d7c12"
 Refs #32668 -- Added gis_enabled argument to get_test_modules().
 }}}

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

Re: [Django] #32823: Cannot pass extra AJAX settings to admin autocomplete

[Django]

#32823: Cannot pass extra AJAX settings to admin autocomplete
---+--
 Reporter:  Seb G  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  autocomplete   | 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
 * type:  Bug => New feature
 * resolution:   => duplicate


Comment:

 Replying to [ticket:32823 Seb G]:
 > This ticket is partly linked to #32628 where the bug was reported along
 with a feature request and got ignored.

 Not ignored but rejected. Again, please don't reopen closed tickets or
 create duplicates. You can start a discussion on DevelopersMailingList if
 you don't agree, see
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets triaging guidelines with regards to wontfix
 tickets.]

 Duplicate of #32628.

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

[Django] #32823: Cannot pass extra AJAX settings to admin autocomplete

[Django]

#32823: Cannot pass extra AJAX settings to admin autocomplete
-+--
   Reporter:  Seb G  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.2
   Severity:  Normal |   Keywords:  autocomplete
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
 This ticket is partly linked to #32628 where the bug was reported along
 with a feature request and got ignored.

 

 The provided JS function `$.fn.djangoAdminSelect2(options)` allows user to
 provide extra options that will be passed to `select2`. But passing extra
 AJAX options does not work as it rewrites the whole `ajax` option object
 instead of extending it.

 Example failing call:

 {{{
 #!javascript
 $(#my-select).djangoAdminSelect2({
 ajax: {
 processResults: function (data) {
 console.log("Foo")
 return data
 }
 }
 });
 }}}

 This call fails because passing an `ajax` object to
 `$.fn.djangoAdminSelect2` erases the whole default `ajax` object including
 the required `ajax.data` default option.

 This failure is caused by the non-recursive call to `$.extend` and can be
 easily resolved by adding the recursive parameter to it.

 I am available to PR this one quickly if 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/049.08b6db2230bffb1dc37dfb4e2bb3a84a%40djangoproject.com.

Re: [Django] #32817: Include in CsrfViewMiddleware's bad CSRF token message where the token is from

[Django]

#32817: Include in CsrfViewMiddleware's bad CSRF token message where the token 
is
from
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  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 Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * 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.06927dd1901d52fc33fe9c6edc59bd6c%40djangoproject.com.

Re: [Django] #32817: Include in CsrfViewMiddleware's bad CSRF token message where the token is from

[Django]

#32817: Include in CsrfViewMiddleware's bad CSRF token message where the token 
is
from
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  CSRF  |  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 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.2bc582295d8bd5b3c0dd00e6d8976e22%40djangoproject.com.