Re: [Django] #30430: Make the admin URL wrap() decorator accessible from anywhere. (was: Make the admin URL wrap decorator accessible from anywhere)

[Django]

#30430: Make the admin URL wrap() decorator accessible from anywhere.
---+--
 Reporter:  Aidas Bendoraitis  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => wontfix


Comment:

 Thanks, for the report, however I don't see much value in adding `wrap()`
 hook to the `ModelAdmin.get_urls()`, you can always use
 `self.admin_site.admin_view()` what is described in
 
[https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_urls
 documentation].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0d8f9dfc336938b18b1387c056ef1cec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30428: Custom tags not loaded. (was: Custom tags not loaded)

[Django]

#30428: Custom tags not loaded.
-+-
 Reporter:  Ozan Gerdaneri   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  templatetags load| Triage Stage:
  fail   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * severity:  Release blocker => Normal
 * version:  2.2 => master
 * ui_ux:  1 => 0
 * resolution:   => worksforme


Comment:

 Thanks for the report, however described code works for me. Please use one
 of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels] for further 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.e174b18851bd16a538aed757c276807e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30430: Make the admin URL wrap decorator accessible from anywhere

[Django]

#30430: Make the admin URL wrap decorator accessible from anywhere
-+
   Reporter:  Aidas Bendoraitis  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |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  |
-+
 In the `get_urls()` of `ModelAdmin`, there is a `wrap()` decorator
 defined. It checks permissions, manages caching, and deals with the CSRF
 protection.

 I would find it useful to make the `wrap()` decorator accessible from an
 outer scope, because so when extending the `get_urls()` you could apply
 the decorator to new views without redefining it.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.d64fa9ab452eca77b1d9114b71214bc2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30429: Allow different response classes in render()

[Django]

#30429: Allow different response classes in render()
-+
   Reporter:  bsolomon1124   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  HTTP handling  |Version:  2.2
   Severity:  Normal |   Keywords:  render
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Add a klass (or maybe response_class) parameter to render() that lets user
 specify a response class other than HttpResponse.

 - Allow any subclass of http.HttpResponseBase
 - Default to http.HttpResponse
 - Do a quick issubclass() check on the argument

 PR: https://github.com/django/django/pull/11162

 What is the motivation for this?

 render() is meant to be a shortcut and a convenience, so I am cautious
 about giving it too many parameters and defeating its original purpose.
 But adding this parameter seems straightforward, frequently useful, and a
 good trade-off in that it's still keeping the function lightweight and
 adding flexibility without code complexity.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.97b148489f0cb3bdfc4836267ef57375%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30428: Custom tags not loaded

[Django]

#30428: Custom tags not loaded
-+-
   Reporter:  ozang  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Template   |Version:  2.2
  system |
   Severity:  Release|   Keywords:  templatetags load
  blocker|  fail
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 Hi,
 I followed the instructions defined in:

 https://docs.djangoproject.com/en/2.2/howto/custom-template-tags/

 Eventhough  {%load poll_extras %} does not give any error, which make me
 think that all the tags defined in the poll_extras .py file loaded
 properly, I cannot access the tags defined in the file.

 For example, this is the tag definition:


 {{{
 from django import template
 register = template.Library()

 @register.simple_tag(name='testtag')
 def some_function():
 return 5

 }}}

 This is the error I got when defined like that  :


 {{{
 {%load poll_extras %}
 {%testtag%}
 }}}


 Invalid block tag on line 89: '"testtag"'. Did you forget to register or
 load this tag?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.6e0f5d1b6bd06f8bcd1e4b0bc36214a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30426: Make security headers default

[Django]

#30426: Make security headers default
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 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 Claude Paroz):

 I was referring to the last sentence of the ticket description:
 > and even changing their global defaults (through a deprecation period)
 so they are activated by default.

 If they are safe defaults, I would be in favor of changing the global
 defaults for these settings. I think we generally strive to make the
 project settings template as short as possible.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.d93d867fdf4f64b342d4c8cc69534dc8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30398: Check database connection's health before its reused

[Django]

#30398: Check database connection's health before its reused
-+-
 Reporter:  Przemysław Suliga|Owner:
 |  Przemysław Suliga
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 Przemysław Suliga):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11311 Proof of Concept 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f9bdfaa2125b2822b27f0ec7b5fe05ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30426: Make security headers default

[Django]

#30426: Make security headers default
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 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 Florian Apolloner):

 * cc: Florian Apolloner (added)


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

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

Re: [Django] #30426: Make security headers default

[Django]

#30426: Make security headers default
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 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 Florian Apolloner):

 Replying to [comment:6 Claude Paroz]:
 > If this is only breaking sites in case of "bad" behavior, I guess we can
 live with a backwards incompatibility note in the release notes.

 It's not even technically backwards incompatible since you only get those
 settings when creating a new project, Adam did not set it in the global
 defaults.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1ab342e9a5d22cf7094af78c1fd7fded%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30426: Make security headers default

[Django]

#30426: Make security headers default
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  2.2
 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 Claude Paroz):

 If this is only breaking sites in case of "bad" behavior, I guess we can
 live with a backwards incompatibility note in the release notes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2a196831184f78661fb998347c303470%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28553: Querysets: annotate() columns are forced into a certain position which may disrupt union()

[Django]

#28553: Querysets: annotate() columns are forced into a certain position which 
may
disrupt union()
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Ole Laursen):

 * cc: Ole Laursen (added)
 * type:  Cleanup/optimization => Bug


Comment:

 There's a ticket with a test case in #30211.

 That ticket was reported as a bug, and I think this ticket should be a bug
 too, so I'm changing the classification for now (apologies if that's
 inappropriate). I think it's a bug because the documentation in my reading
 implies that as long as the columns match, union will work. So it really
 comes as a bit of a surprise that Django overrides the order in
 values_list().

 In my particular case, I'm using union() to combine two different tables
 that I need to get out in sorted order, and I was trying to use annotate()
 + values_list() to add a NULL filler to one table as it lacks a column
 from the other.

 Also, I suppose the ORM could possibly also be a bit more efficient if it
 could return values_list() tuples directly from the select instead of
 having to rearrange them?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.287d3e434ba58b46a28d7867bbab79e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

[Django]

#30375: Use "NO KEY" when doing select_for_update for PostgreSQL
-+-
 Reporter:  Manuel Weitzman  |Owner:  Manuel
 Type:   |  Weitzman
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, lock,  | Triage Stage:  Accepted
  database, operation|
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => assigned
 * needs_better_patch:  0 => 1
 * owner:  nobody => Manuel Weitzman
 * needs_docs:  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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.983d8f3dd55e8af7a408058cd56d558a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26355: Add support for PostgreSQL's array_append to ArrayField

[Django]

#26355: Add support for PostgreSQL's array_append to ArrayField
-+-
 Reporter:  Paul Grau|Owner:  Asif
 |  Saifuddin Auvi
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 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 Asif Saifuddin Auvi):

 * owner:  khorne => Asif Saifuddin Auvi
 * version:  1.9 => master


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.a4bcf788a70fa83e5bf3524c4cdaca90%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30427: Descriptors not accessible for inherited models.

[Django]

#30427: Descriptors not accessible for inherited models.
-+-
 Reporter:  Jarek Glowacki   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  inherited| Triage Stage:  Accepted
  descriptor deferred|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. Described behavior of `models.Model` it's been
 there since at least `1.8` (I didn't check older releases). I'm not sure
 how fixable it is so, I tentatively accept this for future investigation.
 Patch will help with the final decision.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.56ad1729bad219d21740de67ecf87b75%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

[Django]

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  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
-+-

Comment (by Benjamin Schollnick):

 Seeing the same results with 2.2.1.

 As I mentioned before, I have no issues with testing, but I was unable to
 get the Dev GitHub branch to work properly...

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.9c15f98ad099920f4cc8074c90750497%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30409: E012 is raised when ForeignKey is used by "_id" in an Index.

[Django]

#30409: E012 is raised when ForeignKey is used by "_id" in an Index.
--+
 Reporter:  James Cheese  |Owner:  zeynel
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (System checks)  |  Version:  master
 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


Comment:

 In [changeset:"6485a5f450b3dc60e690c31a75e0e9574a896842" 6485a5f4]:
 {{{
 #!CommitTicketReference repository=""
 revision="6485a5f450b3dc60e690c31a75e0e9574a896842"
 Fixed #30409 -- Allowed using foreign key's attnames in
 unique/index_together and Index's fields.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.0e212b8dd9efbe49bc2e5b5c96024b5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27685: Allow autoreloader to use watchman

[Django]

#27685: Allow autoreloader to use watchman
-+-
 Reporter:  Aymeric Augustin |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  master
 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 Ülgen Sarıkavak):

 Is it possible to enable "watchman unavailable" errors back? I understand
 that watchman is not the default option and printing watchman related
 errors as default not a good experience but when i try to install/use
 watchman and something goes wrong, there is no way to what is happening.
 Maybe something like `--force-watchman` or `--reloader=watchman` can do
 the 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c0853bf4c747d76ae84f454889bffc13%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30398: Check database connection's health before its reused

[Django]

#30398: Check database connection's health before its reused
-+-
 Reporter:  Przemysław Suliga|Owner:
 |  Przemysław Suliga
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Przemysław Suliga):

 * owner:  nobody => Przemysław Suliga
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a79464323b70deb6daf8ac22181c39b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.