Re: [Django] #33532: Micro-optimisation: Special-case dictionaries for CaseInsensitiveMapping.

[Django]

#33532: Micro-optimisation: Special-case dictionaries for 
CaseInsensitiveMapping.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  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:

 OK, I'll accept pending discussion on the PR. 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/067.488eb906fd522a72b56f34e1f7d25721%40djangoproject.com.

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Daniel.

 I'm really sorry but I'm failing to see the point you're trying to make
 here... There's clearly something I'm missing because you keep trying to
 get it across to me, but I just don't get it. Can I **please** ask you to
 take a step back and explain it to me from the top clearly so that I can
 see the issue?

 It looks to me like the code we have here when there's no exception in
 `cursor.close()` is equivalent to this:


 {{{
 def will_raise(msg):
 raise Exception(msg)


 try:
 will_raise("Outer")
 except Exception:
 raise
 }}}

 When I run that, I get this output:


 {{{
 % python3 exceptions.py
 Traceback (most recent call last):
   File "/Users/carlton/Desktop/exceptions.py", line 6, in 
 will_raise("Outer")
   File "/Users/carlton/Desktop/exceptions.py", line 2, in will_raise
 raise Exception(msg)
 Exception: Outer
 }}}

 When there **is** an exception in `cursor.close()` it looks like this:

 {{{
 def will_raise(msg):
 raise Exception(msg)


 try:
 will_raise("Outer")
 except Exception:
 will_raise("Inner")
 raise
 }}}


 Which gives this output:


 {{{
 % python3 exceptions.py
 Traceback (most recent call last):
   File "/Users/carlton/Desktop/exceptions.py", line 6, in 
 will_raise("Outer")
   File "/Users/carlton/Desktop/exceptions.py", line 2, in will_raise
 raise Exception(msg)
 Exception: Outer

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/Users/carlton/Desktop/exceptions.py", line 8, in 
 will_raise("Inner")
   File "/Users/carlton/Desktop/exceptions.py", line 2, in will_raise
 raise Exception(msg)
 Exception: Inner
 }}}


 Your suggestion seems to be to make it equivalent to:


 {{{
 def will_raise(msg):
 raise Exception(msg)


 try:
 will_raise("Outer")
 except Exception as o:
 try:
 will_raise("Inner")
 except Exception as i:
 raise i from o
 raise
 }}}

 ... which has the output:


 {{{
 % python3 exceptions.py
 Traceback (most recent call last):
   File "/Users/carlton/Desktop/exceptions.py", line 19, in 
 will_raise("Outer")
   File "/Users/carlton/Desktop/exceptions.py", line 15, in will_raise
 raise Exception(msg)
 Exception: Outer

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/Users/carlton/Desktop/exceptions.py", line 24, in 
 raise i from o
   File "/Users/carlton/Desktop/exceptions.py", line 22, in 
 will_raise("Inner")
   File "/Users/carlton/Desktop/exceptions.py", line 15, in will_raise
 raise Exception(msg)
 Exception: Inner
 }}}

 Which is exactly the same bar the "direct cause" wording change, that was
 agreed on the mailing list discussion to be not worth the verbosity of the
 code change.

 So what's it fixing? (Again: Sorry to not be seeing this, but I'm just not
 getting the point you want to make.)

 > It is meant to fix
 https://code.djangoproject.com/ticket/16614#comment:31 again, which
 regressed.

 But it didn't regress. Both `Outer` and `Inner` are given in the
 traceback. `Outer` is given first, plus the additional info that `Inner`
 occurred whilst we were handling that.
 This behaviour in Python 3 is what justifies the change in
 
https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
 #diff-
 f58de2deaccecd2d53199c5ca29e3e1050ec2adb80fb057cdfc0b4e6accdf14fR878-R879
 — the original error **is** raised.

 If you can put together an actual example of the problem you're hitting
 coming up, that might make it easier. It's very hard to see when it's just
 a couple of lines changed with no test-case or reproduce. (I appreciate
 cursor errors can be hard to test...)

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

-- 
You received this message because you are subscribed to the 

Re: [Django] #33517: Extracting seconds also returns fractional seconds on PostgreSQL and Oracle.

[Django]

#33517: Extracting seconds also returns fractional seconds on PostgreSQL and
Oracle.
-+-
 Reporter:  Joey Lange   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle postgresql| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Mohamed Nabil Rady => (none)
 * status:  assigned => new
 * has_patch:  1 => 0


Comment:

 This is still an issue on Oracle. We could use `EXTRACT(SECOND FROM
 CAST({field_name} AS TIMESTAMP(0)))` but it won't work with
 `DurationField`.

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

Re: [Django] #33517: Extracting seconds also returns fractional seconds on PostgreSQL and Oracle.

[Django]

#33517: Extracting seconds also returns fractional seconds on PostgreSQL and
Oracle.
-+-
 Reporter:  Joey Lange   |Owner:  Mohamed
 |  Nabil Rady
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle postgresql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"b7f263551c64e3f80544892e314ed5b0b22cc7c8" b7f26355]:
 {{{
 #!CommitTicketReference repository=""
 revision="b7f263551c64e3f80544892e314ed5b0b22cc7c8"
 Refs #33517 -- Prevented __second lookup from returning fractional seconds
 on PostgreSQL.
 }}}

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

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

Re: [Django] #33517: Extracting seconds also returns fractional seconds on PostgreSQL and Oracle.

[Django]

#33517: Extracting seconds also returns fractional seconds on PostgreSQL and
Oracle.
-+-
 Reporter:  Joey Lange   |Owner:  Mohamed
 |  Nabil Rady
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle postgresql| 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):

 * keywords:   => oracle postgresql
 * needs_better_patch:  1 => 0


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

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

Re: [Django] #33517: Extracting seconds also returns fractional seconds on PostgreSQL and Oracle. (was: Extracting seconds also returns fractional seconds on PostgreSQL.)

[Django]

#33517: Extracting seconds also returns fractional seconds on PostgreSQL and
Oracle.
-+-
 Reporter:  Joey Lange   |Owner:  Mohamed
 |  Nabil Rady
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 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
-+-

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

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  raydeal
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by raydeal):

 * 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/066.9153c7ad04c219eeb901160ba7cc1462%40djangoproject.com.

Re: [Django] #32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`

[Django]

#32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`
-+-
 Reporter:  Tomasz Wójcik|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (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 raydeal):

 * cc: raydeal (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ceba014ea90d5385e3d076f6e4427173%40djangoproject.com.

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

[Django]

#27844: Add a management command to optimize a migration
-+-
 Reporter:  Raphael Gaschignard  |Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  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/062.8032a34f1add8a93442c42cc2dd6bb0b%40djangoproject.com.

Re: [Django] #33533: Should it be impossible for a session dict to return more than one value for a key?

[Django]

#33533: Should it be impossible for a session dict to return more than one value
for a key?
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

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


Comment:

 See TicketClosingReasons/UseSupportChannels for ways to get help if you
 cannot debug the issue yourself. Please only use this ticket tracker for
 reporting confirmed bugs. 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/068.7ac44b354b3b3337bf21a707b179f434%40djangoproject.com.

[Django] #33533: Should it be impossible for a session dict to return more than one value for a key?

[Django]

#33533: Should it be impossible for a session dict to return more than one value
for a key?
+
   Reporter:  Michael   |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  contrib.sessions  |Version:  4.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In my project, I store the serial number of the device that logs in it's
 session. However in the code that gets the value from the session:

 {{{
 SESSION_SERIAL_NUMBER = 'terminal_serial_number'

 user._serial_number = request.session.get(SESSION_SERIAL_NUMBER, '')
 }}}

 Very occasionally throws an error. The part that baffles me is:

 > get() returned more than one Session -- it returned more than 20!

 How can a dict return more than one result, surely that is a bug for a
 dict to return more than one value?

 Note: When I query the database `django_sessions` table with the given
 `sessionid`, it only returns one row.

 Heres the error (from the email):

 {{{
 Internal Server Error: /accounts/login/

 ProgrammingError at /accounts/login/
 no results to fetch
 }}}

 And the traceback:

 {{{
 Traceback (most recent call last):
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/contrib/sessions/backends/base.py", line 180, in
 _get_session
 return self._session_cache

 During handling of the above exception ('SessionStore' object has no
 attribute '_session_cache'), another exception occurred:
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 47, in inner
 response = get_response(request)
   File "./dist/terminals/middleware.py", line 11, in __call__
 user._serial_number = request.session.get(SESSION_SERIAL_NUMBER, '')
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/contrib/sessions/backends/base.py", line 65, in get
 return self._session.get(key, default)
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/contrib/sessions/backends/base.py", line 185, in
 _get_session
 self._session_cache = self.load()
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/contrib/sessions/backends/db.py", line 43, in load
 s = self._get_session_from_db()
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/contrib/sessions/backends/db.py", line 32, in
 _get_session_from_db
 return self.model.objects.get(
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/db/models/manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/db/models/query.py", line 443, in get
 raise self.model.MultipleObjectsReturned(

 During handling of the above exception (get() returned more than one
 Session -- it returned more than 20!), another exception occurred:
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/contrib/sessions/backends/base.py", line 180, in
 _get_session
 return self._session_cache

 During handling of the above exception ('SessionStore' object has no
 attribute '_session_cache'), another exception occurred:
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/db/utils.py", line 97, in inner
 return func(*args, **kwargs)

 The above exception (no results to fetch) was the direct cause of the
 following exception:
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 47, in inner
 response = get_response(request)
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/utils/deprecation.py", line 126, in __call__
 response = response or self.get_response(request)
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 49, in inner
 response = response_for_exception(request, exc)
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 110, in
 response_for_exception
 response = handle_uncaught_exception(request,
 get_resolver(get_urlconf()), sys.exc_info())
   File "/home/company/.venv/project/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 149, in
 handle_uncaught_exception
 return callback(request)
   File "./core/base/views.py", line 152, in error_500_view
 response = render(request, "core.base/500.html", context=context)
   File "/home/company/.venv/project/lib/python3.8/site-
 

[Django] #33532: Micro-optimisation: Special-case dictionaries for CaseInsensitiveMapping.

[Django]

#33532: Micro-optimisation: Special-case dictionaries for 
CaseInsensitiveMapping.
-+-
   Reporter:  Keryn  |  Owner:  Keryn Knight
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  HTTP   |Version:  dev
  handling   |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently, all data given to `HttpHeaders` and `ResponseHeaders` go
 through `CaseInsensitiveMapping._unpack_items` to unwind in case it's
 ''not'' a dictionary.

 In the case of `HttpHeaders` though, it's ''always'' a dictionary (and
 I've got a plan for `ResponseHeaders` in general, as a separate patch,
 should this one go OK as a pre-requisite), so for the common cases of
 `CaseInsensitiveMapping` being used, we can optimise for the expected use-
 case by **introducing** an additional `isinstance` check to avoid going
 through `_unpack_items`, `__instancecheck__` and `_abc._abc_instancecheck`

 The change itself (I'll add a PR after I get a ticket number) is thus:
 {{{
 -self._store = {k.lower(): (k, v) for k, v in
 self._unpack_items(data)}
 +data = data.items() if isinstance(data, dict) else
 self._unpack_items(data)
 +self._store = {k.lower(): (k, v) for k, v in data}
 }}}

 The isinstance check will **add** roughly `70ns` (for me) to non-dict
 usages of `CaseInsensitiveMapping` (and it's subclasses), but will
 **save**
 roughly `500ns` (for me) when using dictionaries.

 Baseline, main as of `b626c5a9798b045b655d085d59efdd60b5d7a0e3`:
 {{{
 In [1]: from django.http.request import HttpHeaders

 In [2]: from django.utils.datastructures import CaseInsensitiveMapping

 In [3]: %timeit CaseInsensitiveMapping({'Name': 'Jane'})
 1.4 µs ± 7.94 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops
 each)

 In [4]: %timeit HttpHeaders({"HTTP_EXAMPLE": 1})
 2.79 µs ± 20.1 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops
 each)

 In [5]: %timeit HttpHeaders({"CONTENT_LENGTH": 1})
 2.56 µs ± 40 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

 In [6]: %prun for _ in range(10): CaseInsensitiveMapping({"Name":
 "Jane"})
99 function calls (97 primitive calls) in 0.356 seconds
Ordered by: internal time
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
100.0730.0000.2310.000
 datastructures.py:306()
200.0660.0000.1470.000
 datastructures.py:328(_unpack_items)
 10.0630.0630.3560.356 :1()
100.0630.0000.2930.000
 datastructures.py:305(__init__)
100.0300.0000.0720.000 {built-in method
 builtins.isinstance}
100.0220.0000.0410.000
 abc.py:117(__instancecheck__)
100.0190.0000.0200.000 {built-in method
 _abc._abc_instancecheck}
100.0110.0000.0110.000 {method 'lower' of 'str'
 objects}
100.0100.0000.0100.000 {method 'items' of 'dict'
 objects}
 10.0000.0000.3560.356 {built-in method
 builtins.exec}
   2/10.0000.0000.0000.000 {built-in method
 _abc._abc_subclasscheck}
   2/10.0000.0000.0000.000
 abc.py:121(__subclasscheck__)
 20.0000.0000.0000.000
 _collections_abc.py:409(__subclasshook__)
 10.0000.0000.0000.000 {method 'disable' of
 '_lsprof.Profiler' objects}
 }}}

 After adding the patch suggested above:
 {{{
 In [1]: from django.http.request import HttpHeaders

 In [2]: from django.utils.datastructures import CaseInsensitiveMapping

 In [3]: %timeit CaseInsensitiveMapping({'Name': 'Jane'})
 862 ns ± 9.4 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops
 each)

 In [4]: %timeit HttpHeaders({"HTTP_EXAMPLE": 1})
 2.05 µs ± 31 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

 In [5]: %timeit HttpHeaders({"CONTENT_LENGTH": 1})
 1.98 µs ± 18.1 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops
 each)

 In [6]: %prun for _ in range(10): CaseInsensitiveMapping({"Name":
 "Jane"})
53 function calls in 0.204 seconds
Ordered by: internal time
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
100.0840.0000.1480.000
 datastructures.py:305(__init__)
 10.0560.0560.2040.204 :1()
100.0380.0000.0470.000
 datastructures.py:307()
100.0090.000

Re: [Django] #33508: MariaDB 10.8+ supports ordering on individual columns in the index.

[Django]

#33508: MariaDB 10.8+ supports ordering on individual columns in the index.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Alokik
 Type:   |  Roy
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mariadb  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alokik Roy):

 PR [https://github.com/django/django/pull/15452]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a60f3d56a9a8c8f4773257369fb99cda%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:  (none)
 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
---+
Changes (by Markus Holtermann):

 * owner:  Markus Holtermann => (none)
 * status:  assigned => new


Comment:

 Feel free to take over https://github.com/django/django/pull/14147, Blaž.
 I'm not using `TransactionTestCase` anymore at the moment.

-- 
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.1c0645848deb74e2db86450c6fcfca77%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
-+-

Comment (by Blaž Šnuderl):

 Anyone still looking into this? I would be interested to pick this up

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

Re: [Django] #33531: Random ORDER BY not working with MSSQL

[Django]

#33531: Random ORDER BY not working with MSSQL
-+-
 Reporter:  coronoro |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this report, however Django 3.0 is not supported anymore and
 the backend for MSSQL is not built-in. You should report this issue on a
 bug tracker for the 3rd database backend you're using.

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

[Django] #33531: Random ORDER BY not working with MSSQL

[Django]

#33531: Random ORDER BY not working with MSSQL
-+-
   Reporter:  coronoro   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Given a simple Model:

 {{{
 class Person(models.Model):
 name = models.CharField(max_length=100)
 country_code = models.CharField(max_length=3, blank=True, null=True)

 class Meta:
 db_table = 'persons'
 }}}

 I want to pick an entry randomly by using

 {{{
 Person.objects.all().order_by('?')
 }}}

 the resulting query has the following order by clause

 {{{
 ... FROM [persons] ORDER BY RAND() ASC
 }}}

 This however does not give a randomized order of the table. Instead it
 always returns the same entries in the same order(ordered by id).

 The desired result can be achieved with
 {{{
 ... ORDER BY NEWID()
 }}}

 I am aware that this also isn't an exactly optimal solution as stated
 here: [https://dba.stackexchange.com/questions/955/what-is-the-best-way-
 to-get-a-random-ordering].


 For completeness: I observed this behaviour using a MSSQL14 Server

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

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

Re: [Django] #33517: Extracting seconds also returns fractional seconds on PostgreSQL.

[Django]

#33517: Extracting seconds also returns fractional seconds on PostgreSQL.
-+-
 Reporter:  Joey Lange   |Owner:  Mohamed
 |  Nabil Rady
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 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/069.8a7f8e1c13b4a086c87dc41dfe01c451%40djangoproject.com.

Re: [Django] #20296: django.utils.safestring.mark_safe forces evaluation of lazy objects

[Django]

#20296: django.utils.safestring.mark_safe forces evaluation of lazy objects
-+-
 Reporter:  Baptiste Mispelon|Owner:  Theofilos
 |  Alexiou
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  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.99fae68b02f0f0277aa5bd0a23a1ab71%40djangoproject.com.

Re: [Django] #31335: Renaming a ForeignKey included in an index, and removing UniqueConstraint, Index with ForeignKey fails on MySQL.

[Django]

#31335: Renaming a ForeignKey included in an index, and removing 
UniqueConstraint,
Index with ForeignKey fails on MySQL.
-+-
 Reporter:  Stephen Finucane |Owner:  Sergey
 |  Fursov
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 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 Sergey Fursov):

 * needs_better_patch:  1 => 0
 * needs_tests:  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.245675398dea168a09be6ebb189280d0%40djangoproject.com.

Re: [Django] #33522: Unexpected behaviour when logging in

[Django]

#33522: Unexpected behaviour when logging in
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  authentication log   | Triage Stage:
  in CSRF token  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Florian Apolloner, Shai Berger (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.13b667a527c635e5442cb170b3ff93cc%40djangoproject.com.

Re: [Django] #33529: Possibly Incorrect statement in the docs about CRSF tokens

[Django]

#33529: Possibly Incorrect statement in the docs about CRSF tokens
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  4.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Florian Apolloner):

 > I am guessing the new behaviour is if the CSRF Middleware receives a
 request that has the X-CSRFToken header, and a csrftoken key in the POST
 data, it will prefer the POST data?

 Yes it will prefer POST data but I do not think this is new.

 > Maybe a note about how the CSRF Middleware verifies the token when :
 X-CSRFToken header *and* the POST csrftoken entry are *both* provided.
 This is a common scenario if one logs out and in another tab, and uses
 JavaScript Ajax calls that can add both

 This should not happen imo. Normal forms always use the token in the form.
 Ajax should use one or the other but not both. `X-CSRFToken` is mostly
 there if you are posting JSON and not submitting a normal form via Ajax.

 Btw with at least the Django dev version, we verify the origin as well in
 which case the tokens are not used at all :)

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

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

Re: [Django] #33529: Possibly Incorrect statement in the docs about CRSF tokens

[Django]

#33529: Possibly Incorrect statement in the docs about CRSF tokens
--+--
 Reporter:  Michael   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  4.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Michael):

 Replying to [comment:6 Florian Apolloner]:
 > Hi Michael,
 >
 > the CSRF token is POSTed but that does not mean it has to originate from
 the DOM. The middleware operates on the HTTP level, all it sees is post
 data, it has no concept of the DOM. That is why I ment I do not understand
 what the note is (well was, this is fixed in the dev branch) trying to
 say.

 Hi Florian,

 Thanks for this and the clarification of how the admin site handles it. I
 didn't reply to the other points because I was reading up a bit, because I
 think I don't understand the whole system and did not want to waste your
 time. I have also been reading that diff, and I see it changes the text
 from

 The CSRF token is also present in the DOM, but only if explicitly
 included
 using `csrf_token` in a template. The cookie contains the canonical
 token; the ``CsrfViewMiddleware`` will prefer the cookie to the token
 in
 the DOM. Regardless, you're guaranteed to have the cookie if the token
 is
 present in the DOM, so you should use the cookie!

 to

 The CSRF token is also present in the DOM in a masked form, but only
 if
 explicitly included using `csrf_token` in a template. The cookie
 contains the canonical, unmasked token. The
 :class:`~django.middleware.csrf.CsrfViewMiddleware` will accept
 either.
 However, in order to protect against `BREACH`_ attacks, it's
 recommended to
 use a masked token.

 I am guessing the new behaviour is if the CSRF Middleware receives a
 request that has the `X-CSRFToken` header, and a `csrftoken` key in the
 POST data, it will prefer the POST data?

 Maybe a note about how the CSRF Middleware verifies the token when :
 `X-CSRFToken` header *and* the POST  `csrftoken` entry are *both*
 provided. This is a common scenario if one logs out and in another tab,
 and uses JavaScript Ajax calls that can add both:

 E.g.:
 1. There is a POST  `csrftoken` entry, the middleware tries it, and raises
 CSRF exception, even those there is a valid `X-CSRFToken` header

 Or:
 1. There is a POST  `csrftoken` entry, the middleware tries it, fails...
 2.  Check whether there is a `X-CSRFToken` header, it exists and passes,
 request is okay

 Or.
 1. Tries `X-CSRFToken` header first it exists and passes, request is okay

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