Re: [Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  referer,CSRF,CsrfViewMiddleware|
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.a0312be9b08c2fb6851013baba4c04ff%40djangoproject.com.

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   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
-+-
Changes (by Mariusz Felisiak):

 * owner:  Hasan Ramezani => Baptiste Mispelon
 * 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.6e67c9726c731af019c6d1df2eeffb0f%40djangoproject.com.

Re: [Django] #32549: Add `Q.empty()` to check for nested empty Q objects like `Q(Q())`

[Django]

#32549: Add `Q.empty()` to check for nested empty Q objects like `Q(Q())`
-+-
 Reporter:  jonathan-golorry |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Q objects, nested,   | Triage Stage:
  empty  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jonathan-golorry):

 Replying to [comment:6 Ian Foote]:
 > I'm persuaded that this is a problem. Accidentally leaking data because
 we treat {{{Q(Q())}}} differently to {{{Q()}}} feels like a bug to me, so
 fixing it shouldn't be blocked by backwards compatibility arguments.

 #32554 does a lot more to prevent accidentally leaking data. If that's the
 only concern, I think it's better to roll `Q.empty()` into that patch.
 This ticket is primarily about whether or not to shortcut logical
 operations between nested empty Q objects.

-- 
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/074.3cceb40b1172590c3ba9e2649989f027%40djangoproject.com.

[Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type:  Bug| Status:  new
  Component:  CSRF   |Version:  3.1
   Severity:  Normal |   Keywords:
   Triage Stage: |  referer,CSRF,CsrfViewMiddleware
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Django's `CsrfViewMiddleware` assumes that the HTTP referer header is
 valid when checking it. Specifically, it doesn't handle the case of
 `urlparse()` raising a `ValueError` in this line (e.g. for urls like
 `'https://['`):
 
https://github.com/django/django/blob/45814af6197cfd8f4dc72ee43b90ecde305a1d5a/django/middleware/csrf.py#L244

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  new
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 Baptiste Mispelon):

 I wrote a [https://github.com/django/django/pull/14148 new PR] using this
 approach:
 - declaring a list of known boolean attributes
 - using a single logic between `__str__` and `__eq__` (which is now a one-
 liner)

 While writing the patch I noticed that the previous behavior is sortof
 documented, as the documentation for `assertHTMLEqual` [1] says:

 > Attributes without an argument are equal to attributes that equal in
 name and value (see the examples).

 But the example only uses `checked` which is a boolean attribute so I'd
 argue it's not a breaking change.

 [1]
 
https://docs.djangoproject.com/en/dev/topics/testing/tools/#django.test.SimpleTestCase.assertHTMLEqual

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

Re: [Django] #32552: Change DiscoverRunner to use a logger instead of print

[Django]

#32552: Change DiscoverRunner to use a logger instead of print
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,print,logging,stdout,stderr|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniyal Abbasi):

 Sure Carlton! Will be sending a PR soon.

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  new
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 Baptiste Mispelon):

 Using the table you linked to, I get the same list of 24 attributes. The
 table is labelled as "non-normative" but I think it would be good enough
 for this usecase.

 I tried various other ways of extracting the list from the spec but this
 table seems like the best method. It's missing `truespeed` which is a
 boolean attribute for the `` tag (which is deprecated) so I think
 it's acceptable.

 For reference, here's the script I used to get the list (piped to `sort
 -u` to remove duplicates):
 {{{#!py
 from urllib.request import urlopen

 from lxml import html  # needs to be pip-installed (`pip install lxml`)

 if __name__ == '__main__':
 # The spec is an 11Mb file, downloading it takes a while
 response = urlopen('https://html.spec.whatwg.org')
 tree = html.parse(response)

 for i, row in
 enumerate(tree.xpath('.//table[@id="attributes-1"]/tbody/tr')):
 assert len(row) == 4, f"Expected 4 columns on row {i}, got
 {len(rows)}"
 attr, elements, description, value = (node.text_content().strip()
 for node in row)
 if value == "Boolean attribute":
 print(attr)
 }}}

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

Re: [Django] #32568: Prefer SafeString to mark_safe where possible

[Django]

#32568: Prefer SafeString to mark_safe where possible
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  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 Tim McCurrach):

 * version:  3.1 => dev


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

Re: [Django] #16010: Support Origin header checking in the CSRF middleware

[Django]

#16010: Support Origin header checking in the CSRF middleware
-+-
 Reporter:  davidben |Owner:  Tim Graham
 Type:  New feature  |   Status:  assigned
Component:  CSRF |  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"dba44a7a7a3581ec722e06fa0f9f33dfc00ed5cd" dba44a7a]:
 {{{
 #!CommitTicketReference repository=""
 revision="dba44a7a7a3581ec722e06fa0f9f33dfc00ed5cd"
 Refs #16010 -- Required CSRF_TRUSTED_ORIGINS setting to include the
 scheme.
 }}}

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

Re: [Django] #16010: Support Origin header checking in the CSRF middleware

[Django]

#16010: Support Origin header checking in the CSRF middleware
-+-
 Reporter:  davidben |Owner:  Tim Graham
 Type:  New feature  |   Status:  closed
Component:  CSRF |  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:"2411b8b5eb65fe3d7bcc1ee1f59e2433520c7df6" 2411b8b5]:
 {{{
 #!CommitTicketReference repository=""
 revision="2411b8b5eb65fe3d7bcc1ee1f59e2433520c7df6"
 Fixed #16010 -- Added Origin header checking to CSRF middleware.

 Thanks David Benjamin for the original patch, and Florian
 Apolloner, Chris Jerdonek, and Adam Johnson for reviews.
 }}}

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  new
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
-+-
Changes (by Mariusz Felisiak):

 * stage:  Ready for checkin => Accepted


Comment:

 > I've been trying to think about how I would fix the original issue but I
 keep coming back to having an exhaustive list of known boolean attributes
 (the parser already has SELF_CLOSING_TAGS so there's some precedent). I
 don't see how else to fix this correctly.

 Can you prepare such a list? (based on spec). Maybe: `allowfullscreen`,
 `async`, `autofocus`, `autoplay`, `checked`, `controls`,  `default`,
 `defer` , `disabled`, `formnovalidate`, `hidden`, `ismap`, `itemscope`,
 `loop`, `multiple`, `muted`, `nomodule`, `novalidate`, `open`,
 `playsinline`, `readonly`, `required`, `reversed`, `selected` (see
 https://html.spec.whatwg.org/#attributes-3).

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  new
Component:  Testing framework|  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 Baptiste Mispelon):

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


Comment:

 Oh, that was fast. Thanks for the quick turnaround on this, but if I may
 I'd like to reopen this ticket and argue for a revert.

 This test was passing before and now fails (both assertions fail):
 {{{#!py
 def test_boolean_attribute2(self):
 html1 = ''
 html2 = ''
 self.assertHTMLNotEqual(html1, html2)
 self.assertNotEqual(parse_html(html1), parse_html(html2))
 }}}



 I've been trying to think about how I would fix the original issue but I
 keep coming back to having an exhaustive list of known boolean attributes
 (the parser already has `SELF_CLOSING_TAGS` so there's some precedent). I
 don't see how else to fix this correctly.

 On the other hand I'm not opposed to having an incorrect parser with known
 limitations but I think the limitations should be documented.

 I also think that having `__eq__` and `__str__` use separate codepaths
 will lead to more issues. Why can't we have `def __eq__(self, other):
 return str(self) == str(other)`?

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

Re: [Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  dev
 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 Mariusz Felisiak):

 * type:  Bug => Cleanup/optimization
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 This is a minimal example that doesn't raise error messages. I'm not sure
 if it's worth removing this single line, but if it's confusing for anyone
 then we can do 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/067.2b666146920b74ca40eab585938df2e1%40djangoproject.com.

[Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
+
   Reporter:  Aymeric Augustin  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Documentation |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In https://docs.djangoproject.com/en/dev/ref/applications/#for-
 application-authors the example shows `default_auto_field =
 'django.db.models.BigAutoField'` which isn't necessary for the purposes of
 the example ("here’s how you would provide a proper name for the admin")
 and isn't explained either. This may create confusion; I suggest we remove
 this line.

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

Re: [Django] #25251: Inconsistent availability of data from migrations in TestCases when using --keepdb

[Django]

#25251: Inconsistent availability of data from migrations in TestCases when 
using
--keepdb
-+-
 Reporter:  David Szotten|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  1.8
 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 Markus Holtermann):

 * owner:  Romain Garrigues => Markus Holtermann
 * status:  new => assigned


Comment:

 Here's a first draft at restoring data at the end of the test suite:
 https://github.com/django/django/pull/14147

-- 
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/070.a1fd6427bb53fdbb903984b29514351e%40djangoproject.com.

Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:  Accepted
  liveservertestcase, path   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim G):

 WIP is at https://github.com/django/django/pull/14146

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

Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:  Accepted
  liveservertestcase, path   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hey Tim. Yes, do. It’ll highlight what’s going on. We can assess it in
 review.
 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.a901228ba2a195e1e1d899d2e76a1486%40djangoproject.com.

Re: [Django] #25251: Inconsistent availability of data from migrations in TestCases when using --keepdb (was: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb)

[Django]

#25251: Inconsistent availability of data from migrations in TestCases when 
using
--keepdb
-+-
 Reporter:  David Szotten|Owner:  Romain
 |  Garrigues
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 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
-+-

Comment (by Markus Holtermann):

 A few more insights in what's happening:

 1. The issue occurs when ` TransactionTestCase`s are involved.
 2. Data will be unavailable even in regular `TestCase`s.

 Let's assume an empty database. Additionally, the database must support
 transactions (e.g. PostgreSQL or MySQL (but not `MyISAM`)). Let's further
 say you have two test classes (`TestRegular(TestCase)` and
 `TestTx(TransactionTestCase)`) with the test methods `TestRegular.test_1`
 and `TestTx.test_2`.

 * When you run `manage.py test --keepdb` for the first time, Django will
 apply all migrations. That means, data created within those migrations
 will be present.

 * Django runs tests inheriting from `TestCase` before those inheriting
 from `TransactionTestCase`
 
(https://github.com/django/django/blob/9bf5e9418f425666726559c9f1981a516da30aab/django/test/runner.py#L632
 and
 
https://github.com/django/django/blob/9bf5e9418f425666726559c9f1981a516da30aab/django/test/runner.py#L807-L832).
 That means, `test_1()` will be run before `test_2()`.

 * When data should be serialized for a database, Django will insert that
 data during the setup for a test function
 
(https://github.com/django/django/blob/9bf5e9418f425666726559c9f1981a516da30aab/django/test/testcases.py#L1005-L1012).
 This can be enabled explicitly for `TransactionTestCase` using
 `serialized_rollback=True`
 (https://docs.djangoproject.com/en/3.1/topics/testing/overview/#rollback-
 emulation)

 * When a test function in a `TransactionTestCase` is over, Django executes
 the `flush` management command
 
(https://github.com/django/django/blob/9bf5e9418f425666726559c9f1981a516da30aab/django/test/testcases.py#L1063-L1066).
 This empties the database.

 * At the end of the test suite, however, Django does _not_ reinsert
 serialized test data, leaving the database empty after the first
 `--keepdb` run.

 * Running `manage.py test --keepdb` again means, the database is empty
 (has no data that was previously created by the migrations). This means,
 tests in regular `TestCase`s (e.g. `test_1()` will now fail as well.

-- 
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/070.121f4b41396a90cadaa0259ac14bb169%40djangoproject.com.

Re: [Django] #32569: Is there a way to use multiple forward slash URL as one URL?

[Django]

#32569: Is there a way to use multiple forward slash URL as one URL?
-+-
 Reporter:  udoyhasan|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Django, Django URLs  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Please see TicketClosingReasons/UseSupportChannels for places to ask usage
 questions.

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

[Django] #32569: Is there a way to use multiple forward slash URL as one URL?

[Django]

#32569: Is there a way to use multiple forward slash URL as one URL?
-+-
   Reporter:  udoyhasan  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  3.2
  (URLs) |
   Severity:  Normal |   Keywords:  Django, Django URLs
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,
 I'm new to Django. I'm using Django for 5months. I'm now creating a
 project. In that project, I've links like this:

 {{{
 https://localhost:8000/example.com/example/path/
 }}}

 In the URL the example.com/example/path/ can be dynamically long as like
 this

 {{{
 example.com
 }}}

 or

 {{{
 example.com/asset/css/style.css
 }}}

 or


 {{{
  domain.com/core/content/auth/assets/js/vendor/jquery.js
 }}}


 I've used

 {{{
 
 }}}

 But is not working.
 As it has multiple forward slashes. And the forward slashes URL length
 generated while web scrapping.

 So is there is a way to use the full URL as one variable?

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  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:"9bf5e9418f425666726559c9f1981a516da30aab" 9bf5e941]:
 {{{
 #!CommitTicketReference repository=""
 revision="9bf5e9418f425666726559c9f1981a516da30aab"
 Fixed #32556 -- Fixed assertHTMLEqual() to handle empty string as boolean
 attributes value.
 }}}

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

Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:  Accepted
  liveservertestcase, path   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim G):

 Replying to [comment:4 Carlton Gibson]:
 > Tim do you fancy opening a PR with the test at least, so that it's
 easier to work with?

 Sure. I just did that.

 I think I found a fix, but I am not sure if it's the right approach. Shall
 I commit in the PR still?

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

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e3bca22e7e572b0274a0814c7869c899d7b544e0" e3bca22e]:
 {{{
 #!CommitTicketReference repository=""
 revision="e3bca22e7e572b0274a0814c7869c899d7b544e0"
 Refs #31370 -- Made RemoteTestResult subclass unittest.TestResult.
 }}}

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

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"92975bcd5f6281d6124f30cd4a71e0adedd78781" 92975bcd]:
 {{{
 #!CommitTicketReference repository=""
 revision="92975bcd5f6281d6124f30cd4a71e0adedd78781"
 Refs #31370 -- Added test for pickling RemoteTestResult.
 }}}

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

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  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:"f6713cda89d323565cfdc867c977c3363edcfc3c" f6713cda]:
 {{{
 #!CommitTicketReference repository=""
 revision="f6713cda89d323565cfdc867c977c3363edcfc3c"
 Fixed #31370 -- Added support for parallel tests with --buffer.
 }}}

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

Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:  Accepted
  liveservertestcase, path   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Reproduced on Windows 10 (64bit) with the test case provided.

 Tim do you fancy opening a PR with the test at least, so that it's easier
 to work with?

 Thanks again for the report. Really very clear.

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

Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:
  liveservertestcase, path   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hey Tim, nice report thanks.

 I didn't have the time to assess yet, but a couple of questions:

 1. Did you example `request.path` there — what's it look like? What about
 `request.META`?
 2. Does it happen with `runserver` hitting the URL by hand?

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

Re: [Django] #32466: Ticket #29138 breaks autocomplete for inherited models

[Django]

#32466: Ticket #29138 breaks autocomplete for inherited models
-+-
 Reporter:  Dlis |Owner:  Johannes
 |  Maron
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  autocomplete | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"a8fef6daaf75cd24262d973b154fb6580efd99a4" a8fef6da]:
 {{{
 #!CommitTicketReference repository=""
 revision="a8fef6daaf75cd24262d973b154fb6580efd99a4"
 [3.2.x] Fixed #32466 -- Corrected autocomplete to_field resolution for
 complex cases.

 In MTI or ForeignKey as primary key cases, it is required to fetch the
 attname
 from the field instance on the remote model in order to reliably resolve
 the
 to_field_name.

 Backport of ceb4b9ee68dffc6ab0398886f1758f15f037c472 from main Backport of
 03d0f12c823239812da21e5180aaa74dc6fd146e from main

 Co-authored-by: Johannes Maron 
 Co-authored-by: Mariusz Felisiak 
 Co-authored-by: Carlton Gibson 
 }}}

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

Re: [Django] #29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use to_field

[Django]

#29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use
to_field
-+-
 Reporter:  Jonathan Nye |Owner:  Johannes
 |  Maron
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  autocomplete | 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 Carlton Gibson ):

 In [changeset:"0b120f5d649fb21bb898a8b834b6b33e4cdd9504" 0b120f5]:
 {{{
 #!CommitTicketReference repository=""
 revision="0b120f5d649fb21bb898a8b834b6b33e4cdd9504"
 Refs #29138 -- Added extra tests for autocomplete FK to_field variations.
 }}}

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

Re: [Django] #32466: Ticket #29138 breaks autocomplete for inherited models

[Django]

#32466: Ticket #29138 breaks autocomplete for inherited models
-+-
 Reporter:  Dlis |Owner:  Johannes
 |  Maron
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  autocomplete | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"03d0f12c823239812da21e5180aaa74dc6fd146e" 03d0f12c]:
 {{{
 #!CommitTicketReference repository=""
 revision="03d0f12c823239812da21e5180aaa74dc6fd146e"
 Fixed #32466 -- Corrected autocomplete to_field resolution for complex
 cases.

 In MTI or ForeignKey as primary key cases, it is required to fetch the
 attname
 from the field instance on the remote model in order to reliably resolve
 the
 to_field_name.

 Co-authored-by: Johannes Maron 
 Co-authored-by: Mariusz Felisiak 
 Co-authored-by: Carlton Gibson 
 }}}

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  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/067.5b2c679d3b16bc11c5c3198d1f3634bf%40djangoproject.com.

Re: [Django] #32565: Extract URL resolver view strings mapping to admindocs

[Django]

#32565: Extract URL resolver view strings mapping to admindocs
--+
 Reporter:  Adam Johnson  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Negative from PyCharm: they are not using these attributes. And if they’re
 not I’m inclined to punt on no-one really is.

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

Re: [Django] #32568: Prefer SafeString to mark_safe where possible

[Django]

#32568: Prefer SafeString to mark_safe where possible
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  Version:  3.1
 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
-+-
Description changed by Tim McCurrach:

Old description:

> `mark_safe` takes roughly twice as long as simply creating a `SafeString`
> - using pyperf:
> {{{
> mark_safe: Mean +- std dev: 296 ns +- 12 ns
> SafeString: Mean +- std dev: 158 ns +- 7 ns
> }}}
>

> There are many places in the django codebase where we know the thing we
> are marking as safe to be a normal string. In such cases it makes sense
> to use `SafeString` instead of `mark_safe`.
>
> To play devils advocate, you could definitely argue that this is an
> unnecessary micro-optimisation. Following a brief search for `mark_safe`,
> there are some situations where we have something like `mark_safe(X)` and
> where evaluating `X` will take sufficiently long that any savings made
> marking the string as safe would be rendered insignificant.
>
> Having said that, there are other places where we end up calling
> `mark_safe` a very large number of times. In such situations a small
> saving in time will add up to a larger saving. There are also places
> where we even have `mark_safe("some string literal")`.
>
> Furthermore, since this change is literally just replacing one word with
> an equally clear word, it would have no effect on complexity or
> readability, and so for a slight performance boost, why not?

New description:

 `mark_safe` takes roughly twice as long as simply creating a `SafeString`
 - using pyperf:
 {{{
 mark_safe: Mean +- std dev: 296 ns +- 12 ns
 SafeString: Mean +- std dev: 158 ns +- 7 ns
 }}}


 There are many places in the django codebase where we know the thing we
 are marking as safe to be a normal (not marked as safe) string. In such
 cases it makes sense to use `SafeString` instead of `mark_safe`.

 To play devils advocate, you could definitely argue that this is an
 unnecessary micro-optimisation. Following a brief search for `mark_safe`,
 there are some situations where we have something like `mark_safe(X)` and
 where evaluating `X` will take sufficiently long that any savings made
 marking the string as safe would be rendered insignificant.

 Having said that, there are other places where we end up calling
 `mark_safe` a very large number of times. In such situations a small
 saving in time will add up to a larger saving. There are also places where
 we even have `mark_safe("some string literal")`.

 Furthermore, since this change is literally just replacing one word with
 an equally clear word, it would have no effect on complexity or
 readability, and so for a slight performance boost, why not?

--

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

Re: [Django] #32568: Prefer SafeString to mark_safe where possible

[Django]

#32568: Prefer SafeString to mark_safe where possible
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  Version:  3.1
 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 Tim McCurrach):

 * owner:  nobody => Tim McCurrach


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

[Django] #32568: Prefer SafeString to mark_safe where possible

[Django]

#32568: Prefer SafeString to mark_safe where possible
+--
   Reporter:  Tim McCurrach |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Uncategorized |Version:  3.1
   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 |
+--
 `mark_safe` takes roughly twice as long as simply creating a `SafeString`
 - using pyperf:
 {{{
 mark_safe: Mean +- std dev: 296 ns +- 12 ns
 SafeString: Mean +- std dev: 158 ns +- 7 ns
 }}}


 There are many places in the django codebase where we know the thing we
 are marking as safe to be a normal string. In such cases it makes sense to
 use `SafeString` instead of `mark_safe`.

 To play devils advocate, you could definitely argue that this is an
 unnecessary micro-optimisation. Following a brief search for `mark_safe`,
 there are some situations where we have something like `mark_safe(X)` and
 where evaluating `X` will take sufficiently long that any savings made
 marking the string as safe would be rendered insignificant.

 Having said that, there are other places where we end up calling
 `mark_safe` a very large number of times. In such situations a small
 saving in time will add up to a larger saving. There are also places where
 we even have `mark_safe("some string literal")`.

 Furthermore, since this change is literally just replacing one word with
 an equally clear word, it would have no effect on complexity or
 readability, and so for a slight performance boost, why not?

-- 
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/056.2f63618dd393442204e835a523764994%40djangoproject.com.

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  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.c4e1aa0a097ab8b55b0e4505dd50829a%40djangoproject.com.

Re: [Django] #32565: Extract URL resolver view strings mapping to admindocs

[Django]

#32565: Extract URL resolver view strings mapping to admindocs
-+-
 Reporter:  Adam Johnson |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (URLs)  |  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 Adam Johnson):

 I had the thought that, at the very least, we could make generation lazy.

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

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+-
 Reporter:  Baptiste Mispelon|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   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
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14144 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/067.7aeb44654ebab71553927186ce7b9376%40djangoproject.com.

Re: [Django] #32565: Extract URL resolver view strings mapping to admindocs

[Django]

#32565: Extract URL resolver view strings mapping to admindocs
-+-
 Reporter:  Adam Johnson |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (URLs)  |  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 Carlton Gibson):

 Hmmm 🤔 — internally these are only used by admindocs. I wonder if they're
 not being used by tooling somewhere…
 ([https://twitter.com/carltongibson/status/1372504179642601473 asked ref
 PyCharm for an initial data point].)

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

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   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
-+-
Changes (by Adam Johnson):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #32466: Ticket #29138 breaks autocomplete for inherited models

[Django]

#32466: Ticket #29138 breaks autocomplete for inherited models
-+-
 Reporter:  Dlis |Owner:  Johannes
 |  Maron
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autocomplete | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/062.5582b3fadfca4ac62e4dcb9211006570%40djangoproject.com.

Re: [Django] #32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.

[Django]

#32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.
-+-
 Reporter:  François Poulain |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"6b020f3c94fb7f27875d5fe21a71a5ee7c9a7538" 6b020f3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="6b020f3c94fb7f27875d5fe21a71a5ee7c9a7538"
 [3.2.x] Fixed #32547 -- Corrected notes about validation in HTML
 assertions docs.

 Backport of ceb4b9ee68dffc6ab0398886f1758f15f037c472 from main
 }}}

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

Re: [Django] #32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.

[Django]

#32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.
-+-
 Reporter:  François Poulain |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"ceb4b9ee68dffc6ab0398886f1758f15f037c472" ceb4b9e]:
 {{{
 #!CommitTicketReference repository=""
 revision="ceb4b9ee68dffc6ab0398886f1758f15f037c472"
 Fixed #32547 -- Corrected notes about validation in HTML assertions docs.
 }}}

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

Re: [Django] #32549: Add `Q.empty()` to check for nested empty Q objects like `Q(Q())`

[Django]

#32549: Add `Q.empty()` to check for nested empty Q objects like `Q(Q())`
-+-
 Reporter:  jonathan-golorry |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Q objects, nested,   | Triage Stage:
  empty  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ian Foote):

 I'm persuaded that this is a problem. Accidentally leaking data because we
 treat {{{Q(Q())}}} differently to {{{Q()}}} feels like a bug to me, so
 fixing it shouldn't be blocked by backwards compatibility arguments.

-- 
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/074.30c13e1e674e46f1995936ec826ffea4%40djangoproject.com.

Re: [Django] #32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.

[Django]

#32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.
-+-
 Reporter:  François Poulain |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/066.795a0842320583f7660db21c16bdabfe%40djangoproject.com.

Re: [Django] #32563: Cannot override database used with RelatedManager

[Django]

#32563: Cannot override database used with RelatedManager
-+-
 Reporter:  Lucas Gruber |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  RelatedManager   | Triage Stage:
  mullti databases   |  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:

 Lucas, I'm not exactly sure how you would like to use `using` in `set()`.
 There is no need to specify a database alias for `set()` because it uses
 `db_alias` from the instance. As far as I'm aware that's the only database
 that makes sense in this case. Cross-database foreign keys and m2m fields
 are not supported in Django, see #12540.

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

Re: [Django] #32563: Cannot override database used with RelatedManager

[Django]

#32563: Cannot override database used with RelatedManager
-+-
 Reporter:  Lucas Gruber |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  RelatedManager   | Triage Stage:
  mullti databases   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Lucas Gruber:

Old description:

> I suppose an app with models:
> {{{
> 
> class Blog(models.Model):
> title = models.CharField(max_length=100)
>
> class Person(models.Model):
> name = models.CharField(max_length=100)
> subscribed_blogs = models.ManyToManyField(Blog,
> related_name="subscribers", through="Subscription")
>
> class Subscription(models.Model):
> person = models.ForeignKey(Person, related_name="subscriptions")
> blog = models.ForeignKey(Blog, related_name="subscriptions")
> 
> }}}
>
> In thes case we are using multiple databases and we need to create custom
> migration, we have to write something like
> {{{
> 
> def custom_migrations(apps, schema_editor):
> db_alias = schema_editor.connection.alias
>
> person = Person.objects.using(db_alias).get(pk=1)
> blog = Blog.objects.using(db_alias).get(pk=1)
> blog.subscribers.set([person])
>
> blog.save(using=db_alias)
>
> 
> }}}
>
> The line blog.subscribers.set(...) does not permit to add parameter for
> overriding database to use.
> The source code for this function is in
> django.db.models.fields.related_descriptors when we can see:
> {{{
> [...]
> def set(self, objs, *, clear=False, through_defaults=None):
> # Force evaluation of `objs` in case it's a queryset whose
> value
> # could be affected by `manager.clear()`. Refs #19816.
> objs = tuple(objs)
>
> db = router.db_for_write(self.through,
> instance=self.instance)
> with transaction.atomic(using=db, savepoint=False):
> if clear:
> self.clear()
> self.add(*objs, through_defaults=through_defaults)
> else:
> old_ids =
> set(self.using(db).values_list(self.target_field.target_field.attname,
> flat=True))
>
> new_objs = []
> for obj in objs:
> fk_val = (
> self.target_field.get_foreign_related_value(obj)[0]
> if isinstance(obj, self.model) else obj
> )
> if fk_val in old_ids:
> old_ids.remove(fk_val)
> else:
> new_objs.append(obj)
>
> self.remove(*old_ids)
> self.add(*new_objs,
> through_defaults=through_defaults)
> [...]
> }}}
>
> Code always calls database router, but in migration process, the router
> can not find the appropriate database because we just use without request
> :
> {{{
> python manage.py migrate --database db2
> }}}
>
> I noticed that all the methods of ''RelatedManager'' directly call the
> router object to find the database while the ''Manager'' objects always
> exploits the possibility of overriding the database with the call to
> ''using()'' on the QuerySet or to pass parameter ''using=db'' for save
> model method for example.
>
> I guess we need to use a mecanism which we can find in Model class with
> the save method :
> {{{
> def save(self, force_insert=False, force_update=False, using=None,
>  update_fields=None):
> [...]
> using = using or router.db_for_write(self.__class__,
> instance=self)
> [...]
> }}}
>
> Thus, we will be able to override the database at the time of the save.
>
> Thank you in advance for your answer

New description:

 I suppose an app with models:
 {{{
 
 class Blog(models.Model):
 title = models.CharField(max_length=100)

 class Person(models.Model):
 name = models.CharField(max_length=100)
 subscribed_blogs = models.ManyToManyField(Blog,
 related_name="subscribers", through="Subscription")

 class Subscription(models.Model):
 person = models.ForeignKey(Person, related_name="subscriptions")
 blog = models.ForeignKey(Blog, related_name="subscriptions")
 
 }}}

 In thes case we are using multiple databases and we need to c

Re: [Django] #32563: Cannot override database used with RelatedManager

[Django]

#32563: Cannot override database used with RelatedManager
-+-
 Reporter:  Lucas Gruber |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  RelatedManager   | Triage Stage:
  mullti databases   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Lucas Gruber:

Old description:

> I suppose an app with models:
> {{{
> 
> class Blog(models.Model):
> title = models.CharField(max_length=100)
>
> class Person(models.Model):
> name = models.CharField(max_length=100)
> subscribed_blogs = models.ManyToManyField(Blog,
> related_name="subscribers", through="Subscription")
>
> class Subscription(models.Model):
> person = models.ForeignKey(Person, related_name="subscriptions")
> blog = models.ForeignKey(Blog, related_name="subscriptions")
> 
> }}}
>
> In thes case we are using multiple databases and we need to create custom
> migration, we have to write something like
> {{{
> 
> def custom_migrations(apps, schema_editor):
> db_alias = schema_editor.connection.alias
>
> person = Person.objects.using(db_alias).get(pk=1)
> blog = Blog.objects.using(db_alias).get(pk=1)
> blog.subscribers.set([person])
>
> blog.save(using=db_alias)
>
> 
> }}}
>
> The line blog.subscribers.set(...) does not permit to add parameter for
> overriding database to use.
> The source code for this function is in
> django.db.models.fields.related_descriptors when we can see:
> {{{
> [...]
> def set(self, objs, *, clear=False, through_defaults=None):
> # Force evaluation of `objs` in case it's a queryset whose
> value
> # could be affected by `manager.clear()`. Refs #19816.
> objs = tuple(objs)
>
> db = router.db_for_write(self.through,
> instance=self.instance)
> with transaction.atomic(using=db, savepoint=False):
> if clear:
> self.clear()
> self.add(*objs, through_defaults=through_defaults)
> else:
> old_ids =
> set(self.using(db).values_list(self.target_field.target_field.attname,
> flat=True))
>
> new_objs = []
> for obj in objs:
> fk_val = (
> self.target_field.get_foreign_related_value(obj)[0]
> if isinstance(obj, self.model) else obj
> )
> if fk_val in old_ids:
> old_ids.remove(fk_val)
> else:
> new_objs.append(obj)
>
> self.remove(*old_ids)
> self.add(*new_objs,
> through_defaults=through_defaults)
> [...]
> }}}
>
> Code always calls database router, but in migration process, the router
> can not find the appropriate database because we just use without request
> :
> {{{
> python manage.py migrate --database db2
> }}}
>
> I noticed that all the methods of ''RelatedManager'' directly call the
> router object to find the database while the ''Manager'' objects always
> exploits the possibility of overriding the database with the call to
> ''using()'' on the QuerySet or to pass parameter ''using=db'' for save
> model method for example.
>

> Thank you in advance for your answer

New description:

 I suppose an app with models:
 {{{
 
 class Blog(models.Model):
 title = models.CharField(max_length=100)

 class Person(models.Model):
 name = models.CharField(max_length=100)
 subscribed_blogs = models.ManyToManyField(Blog,
 related_name="subscribers", through="Subscription")

 class Subscription(models.Model):
 person = models.ForeignKey(Person, related_name="subscriptions")
 blog = models.ForeignKey(Blog, related_name="subscriptions")
 
 }}}

 In thes case we are using multiple databases and we need to create custom
 migration, we have to write something like
 {{{
 
 def custom_migrations(apps, schema_editor):
 db_alias = schema_editor.connection.alias

 person = Person.objects.using(db_alias).get(pk=1)
 blog = Blog.objects.using(db_alias).get(pk=1)
 blog.subscribers.set([person])

 blog.save(using=db_alias)

 
 }}}

 The lin

Re: [Django] #32563: Cannot override database used with RelatedManager

[Django]

#32563: Cannot override database used with RelatedManager
-+-
 Reporter:  Lucas Gruber |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  RelatedManager   | Triage Stage:
  mullti databases   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Lucas Gruber):

 * status:  closed => new
 * resolution:  invalid =>


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

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/068.28a889704632e77c2bd6d190720c4599%40djangoproject.com.