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

[Django]

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

Comment (by Nick Pope):

 Replying to [comment:4 Marten Kenbeek]:
 > To be clear, you're talking about logical `XOR`, and not bitwise `XOR`?

 As you've highlighted, this should be for logical `XOR` and not bitwise
 `XOR`. So this is only supported for MariaDB and MySQL which have `XOR`.

 This could be implemented by defining `Q.XOR` and `Q.__xor__()` and then
 propagating that around the place.
 It could be possible to support this for other backends by specifying
 `connection.features.supports_logical_xor = False` and then writing out
 the query differently.

 For `Q(a=1) ^ Q(b=2)`, the supporting backends would output `(a = 1 XOR a
 = 2)`, while the others could output `((a = 1 OR b = 2) AND NOT (a = 1 AND
 b = 2))`.

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

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

Re: [Django] #30664: SQLite3 migrations can fail when used quoted db_table.

[Django]

#30664: SQLite3 migrations can fail when used quoted db_table.
-+-
 Reporter:  Maciej Olko  |Owner:  Ngalim
 |  Siregar
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  quoted, db_table,| Triage Stage:  Accepted
  meta, model, sqlite3, syntax-  |
  error  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ngalim Siregar):

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

Re: [Django] #30664: SQLite3 migrations can fail when used quoted db_table.

[Django]

#30664: SQLite3 migrations can fail when used quoted db_table.
-+-
 Reporter:  Maciej Olko  |Owner:  Ngalim
 |  Siregar
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  quoted, db_table,| Triage Stage:  Accepted
  meta, model, sqlite3, syntax-  |
  error  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ngalim Siregar):

 Sorry, I was misunderstood the intent. I have made the requested changes;
 please review again

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

Re: [Django] #30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?

[Django]

#30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?
-+-
 Reporter:  Lincoln  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FILE_UPLOAD_MAX_MEMORY_SIZE,   |
  None, settings |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"eea0bf7bd58cda4618ecc10133f0ad09effe1a2e" eea0bf7b]:
 {{{
 #!CommitTicketReference repository=""
 revision="eea0bf7bd58cda4618ecc10133f0ad09effe1a2e"
 Refs #30669 -- Removed incorrect branch in ASGIHander.read_body().

 None is not valid for settings.FILE_UPLOAD_MAX_MEMORY_SIZE.
 Always use SpooledTemporaryFile.
 }}}

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

Re: [Django] #30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?

[Django]

#30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?
-+-
 Reporter:  Lincoln  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FILE_UPLOAD_MAX_MEMORY_SIZE,   |
  None, settings |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 [https://github.com/django/django/pull/11614 PR removing the `is None`
 branch].

 Not sure currently if/what we want to do about the rest of the discussion.

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

Re: [Django] #30665: Add DISTINCT support for Avg and Sum aggregates.

[Django]

#30665: Add DISTINCT support for Avg and Sum aggregates.
-+-
 Reporter:  Étienne Beaulé   |Owner:  Étienne
 |  Beaulé
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"5f24e7158e1d5a7e40fa0ae270639f6a171bb18e" 5f24e715]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f24e7158e1d5a7e40fa0ae270639f6a171bb18e"
 Fixed #30665 -- Added support for distinct argument to Avg() and Sum().
 }}}

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

Re: [Django] #30665: Add DISTINCT support for Avg and Sum aggregates.

[Django]

#30665: Add DISTINCT support for Avg and Sum aggregates.
-+-
 Reporter:  Étienne Beaulé   |Owner:  Étienne
 |  Beaulé
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Yes :) I checked this more carefully and reverted title change.

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

Re: [Django] #30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?

[Django]

#30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?
-+-
 Reporter:  Lincoln  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FILE_UPLOAD_MAX_MEMORY_SIZE,   |
  None, settings |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 > As it stands if the request is "unlimited" we'd end up using a lot™ of
 disk space.

 But this applies equally to the existing WSGI code right? Django doesn't
 have a limit on the total file data that can be uploaded. (Does it? — I've
 always set a sensible value at the nginx level...)

 The only difference here is we have this extra buffer layer. (So we read
 the bytes, presumably to disk, twice, for the length of the request.)

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

Re: [Django] #30665: Add DISTINCT support for Avg and Sum aggregates. (was: Add DISTINCT support for Avg, Sum, StdDev, and Variance aggregates.)

[Django]

#30665: Add DISTINCT support for Avg and Sum aggregates.
-+-
 Reporter:  Étienne Beaulé   |Owner:  Étienne
 |  Beaulé
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

Re: [Django] #30665: Add DISTINCT support for Avg, Sum, StdDev, and Variance aggregates. (was: Add DISTINCT support for Avg and Sum aggregates.)

[Django]

#30665: Add DISTINCT support for Avg, Sum, StdDev, and Variance aggregates.
-+-
 Reporter:  Étienne Beaulé   |Owner:  Étienne
 |  Beaulé
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Étienne Beaulé):

 Must disagree, felixxm. Neither `StdDev` nor `Variance` is in scope for
 this task as using the `DISTINCT` keyword on these aggregates is not as
 widely supported by SQL backends (such as Oracle). Supporting these would
 require more involved work. Some discussion was had about using
 `check_expression_support()` in
 [https://github.com/django/django/pull/9174 GH9174] but was dropped.

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

Re: [Django] #30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?

[Django]

#30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?
-+-
 Reporter:  Lincoln  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FILE_UPLOAD_MAX_MEMORY_SIZE,   |
  None, settings |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * component:  File uploads/storage => HTTP handling


Comment:

 Replying to [comment:4 Claude Paroz]:
 > I'm not sure about your explanation of later size check. What if a
 request has "unlimited" (i.e. *very* big) length?

 OK, so this is where it get's tricky. 

 As it stands if the request is "unlimited" we'd end up using **a lot™** of
 disk space. Whatever frontend server is in play should put an absolute
 limit on request sizes, and we could document the need for that in the
 deployment checklist, but we should have some kind of ceiling here.

 `DATA_UPLOAD_MAX_MEMORY_SIZE` is not really the correct measure. **At this
 point** we want to limit the total size of the request.
 `DATA_UPLOAD_MAX_MEMORY_SIZE` is applied to only to the `POST` data, with
 `FILES` being handled separately (in MultipartParser, as you point to
 Claude.) The danger is we limit total request size to
 `DATA_UPLOAD_MAX_MEMORY_SIZE` and in so doing stop people handling large
 file uploads.

 So, total request size should be limited to (something like) the amount of
 POST data I want to handle in memory (`DATA_UPLOAD_MAX_MEMORY_SIZE`) plus
 the maximum file size I want to allow to be uploaded (which isn't
 `FILE_UPLOAD_MAX_MEMORY_SIZE` either).

 Whilst we need to read in the request here, I guess we can decide a
 generous but sensible default, and allow folks to set their own value.
 Personally I'd rather avoid a setting  and let people pass a parameter in
 their `asgi.py` when instantiating the application (or use an
 `ASGIHandler` subclass which specifies it) but what do others think?

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

Re: [Django] #30665: Add DISTINCT support for Avg, Sum, StdDev, and Variance aggregates. (was: Add DISTINCT support for Avg and Sum aggregates.)

[Django]

#30665: Add DISTINCT support for Avg, Sum, StdDev, and Variance aggregates.
-+-
 Reporter:  Étienne Beaulé   |Owner:  Étienne
 |  Beaulé
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

Re: [Django] #30160: Support more archive formats (e.g. .tar.xz) for app and project templates

[Django]

#30160: Support more archive formats (e.g. .tar.xz) for app and project 
templates
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startapp,| Triage Stage:  Accepted
  startproject, lzma, xz |
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:"1692f69e37ccf7985a1f62875babab91984b9773" 1692f69e]:
 {{{
 #!CommitTicketReference repository=""
 revision="1692f69e37ccf7985a1f62875babab91984b9773"
 Refs #30160 -- Doc'd startapp/startproject support for tarfile templates.
 }}}

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

Re: [Django] #30160: Support more archive formats (e.g. .tar.xz) for app and project templates

[Django]

#30160: Support more archive formats (e.g. .tar.xz) for app and project 
templates
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startapp,| Triage Stage:  Accepted
  startproject, lzma, xz |
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:"69a30f620eb46246c0b39cd40a0f7df57f2af8d0" 69a30f62]:
 {{{
 #!CommitTicketReference repository=""
 revision="69a30f620eb46246c0b39cd40a0f7df57f2af8d0"
 Refs #30160 -- Simplified archive extension map and added other aliases.
 }}}

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

Re: [Django] #30160: Support more archive formats (e.g. .tar.xz) for app and project templates

[Django]

#30160: Support more archive formats (e.g. .tar.xz) for app and project 
templates
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startapp,| Triage Stage:  Accepted
  startproject, lzma, xz |
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:"c95d063e776e849cf1a0bf616c654165cb89c706" c95d063]:
 {{{
 #!CommitTicketReference repository=""
 revision="c95d063e776e849cf1a0bf616c654165cb89c706"
 Refs #30160 -- Simplified and improved tests for django.utils.archive.

 The file executable should have 0o775 permission not only u=x.
 The file no_permissions should have 0o644 u=r.
 }}}

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

Re: [Django] #30160: Support more archive formats (e.g. .tar.xz) for app and project templates

[Django]

#30160: Support more archive formats (e.g. .tar.xz) for app and project 
templates
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  startapp,| Triage Stage:  Accepted
  startproject, lzma, xz |
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:"f618e033acd37d59b536d6e6126e6c5be18037f6" f618e033]:
 {{{
 #!CommitTicketReference repository=""
 revision="f618e033acd37d59b536d6e6126e6c5be18037f6"
 Fixed #30160 -- Added support for LZMA and XZ templates to
 startapp/startproject management commands.
 }}}

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

Re: [Django] #30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?

[Django]

#30669: Can FILE_UPLOAD_MAX_MEMORY_SIZE be set to None?
-+-
 Reporter:  Lincoln  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  master
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FILE_UPLOAD_MAX_MEMORY_SIZE,   |
  None, settings |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Godwin):

 I agree that there's no situation it should be None - the "is None"
 statement is likely a leftover from my testing and development.

 DATA_UPLOAD_MAX_MEMORY_SIZE may well be the right thing to use - I would
 appreciate other people's opinion on this one since it's not totally clear
 to me how the failure/enforcement modes of those two settings are defined.

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