Re: [Django] #32940: Consider removing unused/unnecessary functionality in tree.Node.add

[Django]

#32940: Consider removing unused/unnecessary functionality in tree.Node.add
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


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

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

Re: [Django] #32940: Consider removing unused/unnecessary functionality in tree.Node.add

[Django]

#32940: Consider removing unused/unnecessary functionality in tree.Node.add
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"fb35e0a2feb36e60b93a12dd43eb9eed2015adda" fb35e0a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="fb35e0a2feb36e60b93a12dd43eb9eed2015adda"
 Refs #32940 -- Removed Node.add()'s unused squash parameter.

 Unused since its introduction in d3f00bd5706b35961390d3814dd7e322ead3a9a3.

 Co-authored-by: Nick Pope 
 }}}

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

Re: [Django] #32940: Consider removing unused/unnecessary functionality in tree.Node.add

[Django]

#32940: Consider removing unused/unnecessary functionality in tree.Node.add
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"ff661dbd506efbdf51cc8da89cb98731c8a62f49" ff661db]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff661dbd506efbdf51cc8da89cb98731c8a62f49"
 Refs #32940 -- Removed unnecessary branch in Node.add().

 The "data in self.children" branch was causing data.__eq__ to be
 called for each entries in "self.children" which resulted in a huge
 slowdown during queryset construction.

 It's purpose was to prevent queries of the form
 Model.objects.filter(foo='bar').filter(foo='bar')
 from resulting in
 WHERE foo='bar' AND foo='bar'
 but it's not covered by the suite and has arguable performance benefits
 since it's not very common and SQL engines are usually very good at
 folding/optimizing these.

 See also #32632 for prior discussion around comparing data to the
 Node's children.

 Co-authored-by: Nick Pope 
 }}}

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

Re: [Django] #32944: Simplify where clause creation where the WhereNode is immediately created and then added to and then returned.

[Django]

#32944: Simplify where clause creation where the WhereNode is immediately 
created
and then added to and then returned.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

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

Re: [Django] #32945: Improve performance of HttpRequest._current_scheme_host()

[Django]

#32945: Improve performance of HttpRequest._current_scheme_host()
-+-
 Reporter:  David Smith  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Uncategorized => HTTP handling
 * type:  Uncategorized => Cleanup/optimization


Comment:

 Thanks for this proposition, however I don't think it's worth changing. I
 don't see a significant improvement in Python 3.8:
 {{{
 .
 Current: Mean +- std dev: 29.4 us +- 1.9 us
 .
 Option One: Mean +- std dev: 28.9 us +- 0.7 us
 .
 Option Two: Mean +- std dev: 28.9 us +- 0.7 us
 .
 Option Three: Mean +- std dev: 29.2 us +- 1.5 us
 }}}
 and in Python 3.10 is even worse:
 {{{
 .
 Current: Mean +- std dev: 34.4 us +- 1.2 us
 .
 Option One: Mean +- std dev: 34.2 us +- 0.9 us
 .
 Option Two: Mean +- std dev: 34.7 us +- 0.9 us
 .
 Option Three: Mean +- std dev: 34.8 us +- 0.9 us
 }}}

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

Re: [Django] #32704: QuerySet.defer() doesn't clear deferred field when chaining with only().

[Django]

#32704: QuerySet.defer() doesn't clear deferred field when chaining with only().
-+-
 Reporter:  Manuel Baclet|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  defer only   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (added)
 * owner:  nobody => David Wobrock
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 Hey all,

 Replying to [comment:6 Mariusz Felisiak]:
 > Replying to [comment:5 Manuel Baclet]:
 > >
 > > With your patch proposal, i do not think that:
 > > `Company.objects.only("name").defer("name").defer("country")` is
 equivalent to `Company.objects.only("name").defer("name", "country")`
 >
 > Did you check this? with proposed patch `country` is the only deferred
 fields in both cases. As far as I'm aware that's an intended behavior.

 I believe Manuel is right. This happens because the set difference in one
 direction gives you the empty set that will clear out the deferred fields
 - but it is missing the fact that we might also be adding more `defer`
 fields than we had `only` fields in the first place, so that we actually
 switch from an `.only()` to a `.defer()` mode.

 See the corresponding PR that should fix this behaviour
 https://github.com/django/django/pull/14667

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

Re: [Django] #27147: Add support for defining bounds in postgres range fields

[Django]

#27147: Add support for defining bounds in postgres range fields
-+-
 Reporter:  Kirill Stepanov  |Owner:  Guilherme
 |  Martins Crocetti
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgres range   | Triage Stage:  Accepted
  bounds |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * has_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/065.7fac454d914a16fff09ffc74b8eef2aa%40djangoproject.com.

[Django] #32945: Improve performance of HttpRequest._current_scheme_host()

[Django]

#32945: Improve performance of HttpRequest._current_scheme_host()
-+
   Reporter:  David Smith|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 `_current_scheme_host()` currently uses `.format`. I propose that we
 change this to an `f-string` for a c.7.5% performance gain.

 There's a few different ways this could be written, I think OptionTwo
 would be the one which would meet Django's f-string guidelines. I've shown
 a few different versions to show that moving to f-string is the big win
 here and adding a few extra variables (or not) as no impact.

 One thing to note is that this function is decorated with
 `cached_property` but I've removed this to benchmark the underlying
 function.


 {{{
 .
 Current: Mean +- std dev: 243 us +- 4 us
 .
 Option One: Mean +- std dev: 226 us +- 2 us
 .
 Option Two: Mean +- std dev: 225 us +- 3 us
 .
 Option Three: Mean +- std dev: 226 us +- 2 us
 }}}

 {{{
 import pyperf
 from django.conf import settings
 from django.http import HttpRequest
 import django


 settings.configure(ALLOWED_HOSTS = ['localhost'])
 django.setup()

 class CurrentHttpRequest(HttpRequest):
 def _current_scheme_host(self):
 return '{}://{}'.format(self.scheme, self.get_host())

 class OptionOneHttpRequest(HttpRequest):
 def _current_scheme_host(self):
 return f'{self.scheme}://{self.get_host()}'

 class OptionTwoHttpRequest(HttpRequest):
 def _current_scheme_host(self):
 host = self.get_host()
 return f'{self.scheme}://{host}'

 class OptionThreeHttpRequest(HttpRequest):
 def _current_scheme_host(self):
 scheme = self.scheme
 host = self.get_host()
 return f'{scheme}://{host}'

 def current(loops):
 request = CurrentHttpRequest()
 request.META['SERVER_NAME'] = 'localhost'
 request.META['SERVER_PORT'] = '80'
 range_it = range(loops)
 t0 = pyperf.perf_counter()

 for loop in range_it:
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()

 return pyperf.perf_counter() - t0

 def option_one(loops):
 request = OptionOneHttpRequest()
 request.META['SERVER_NAME'] = 'localhost'
 request.META['SERVER_PORT'] = '80'
 range_it = range(loops)
 t0 = pyperf.perf_counter()

 for loop in range_it:
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()

 return pyperf.perf_counter() - t0

 def option_two(loops):
 request = OptionTwoHttpRequest()
 request.META['SERVER_NAME'] = 'localhost'
 request.META['SERVER_PORT'] = '80'
 range_it = range(loops)
 t0 = pyperf.perf_counter()

 for loop in range_it:
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()

 return pyperf.perf_counter() - t0

 def option_three(loops):
 request = OptionThreeHttpRequest()
 request.META['SERVER_NAME'] = 'localhost'
 request.META['SERVER_PORT'] = '80'
 range_it = range(loops)
 t0 = pyperf.perf_counter()

 for loop in range_it:
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()
 request._current_scheme_host()

 return pyperf

Re: [Django] #20205: PositiveIntegerfield does not handle empty values well

[Django]

#20205: PositiveIntegerfield does not handle empty values well
-+-
 Reporter:  anonymous|Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  assigned
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:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * owner:  Amine Zyad => Jacob Walls
 * needs_better_patch:  1 => 0


Comment:

 It seems curious that under the status quo, where `empty_strings_allowed`
 is False, that we would skip model validation even at the moment we are
 holding an empty string (as opposed to None or any of the other values in
 `empty_values`). [https://github.com/django/django/pull/14666 PR to run
 model validation in this case.]

 However, we could also treat as a duplicate of #4 and add either
 [Simon's friendly guardrail
 https://code.djangoproject.com/ticket/4#comment:5] for folks without a
 solution for MyModel.clean() or just wontfix.

 Happy to hear advice or to be nudged toward the mailing list.

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

Re: [Django] #10929: Support a default value for Sum (and possibly other aggregation functions)

[Django]

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
-+-
 Reporter:  nolan|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate annotate   | Triage Stage:  Ready for
  default|  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:"501a8db46595b2d5b99c1d3b1146a832f43cdf1c" 501a8db4]:
 {{{
 #!CommitTicketReference repository=""
 revision="501a8db46595b2d5b99c1d3b1146a832f43cdf1c"
 Fixed #10929 -- Added default argument to aggregates.

 Thanks to Simon Charette and Adam Johnson for the 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/063.4e8cd0c0eb5a6ad4a912c2615087a605%40djangoproject.com.

Re: [Django] #10929: Support a default value for Sum (and possibly other aggregation functions)

[Django]

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
-+-
 Reporter:  nolan|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate annotate   | Triage Stage:  Ready for
  default|  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:"fee87345967b3d917b618533585076cbfa43451b" fee87345]:
 {{{
 #!CommitTicketReference repository=""
 revision="fee87345967b3d917b618533585076cbfa43451b"
 Refs #10929 -- Deprecated forced empty result value for PostgreSQL
 aggregates.

 This deprecates forcing a return value for ArrayAgg, JSONBAgg, and
 StringAgg when there are no rows in the query. Now that we have a
 ``default`` argument for aggregates, we want to revert to returning the
 default of ``None`` which most aggregate functions return and leave it
 up to the user to decide what they want to be returned by default.
 }}}

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

Re: [Django] #32943: Add support for covering indexes and exclusion constraints for SP-GiST in PostgreSQL 14+.

[Django]

#32943: Add support for covering indexes and exclusion constraints for SP-GiST 
in
PostgreSQL 14+.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql, spgist,  | Triage Stage:
  index, exclusion, constraint,  |  Someday/Maybe
  include, covering  |
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 => Someday/Maybe


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

Re: [Django] #32927: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU with gdal 3.3.1

[Django]

#32927: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU with
gdal 3.3.1
-+-
 Reporter:  szunami  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 If you have any additional details, please add a comment to the #32600,
 see also comments [https://code.djangoproject.com/ticket/32600#comment:2
 2] and [https://code.djangoproject.com/ticket/32600#comment:3 3].
 Currently we cannot prove that Django is at fault.

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

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

Re: [Django] #22224: Non-nullable blank string-based model field validation doesn't prevent or clean `None`

[Django]

#4: Non-nullable blank string-based model field validation doesn't prevent 
or
clean `None`
-+-
 Reporter:  Simon Charette   |Owner:  nobody
 Type:  Bug  |   Status:  new
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:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jacob Walls):

 Well, I came here to suggest `wontfix`, but
 [https://code.djangoproject.com/ticket/4#comment:5 Simon's batteries-
 included proposal] is starting to tempt me.

 This test case from 2010 indicates the supported design pattern that the
 naive fix to this ticket (run model validation on blankable/not-nullable
 fields instead of short-circuiting, as now) would break:

 {{{
 def test_validation_with_empty_blank_field(self):
 # Since a value for pub_date wasn't provided and the field is
 # blank=True, model-validation should pass.
 # Also, Article.clean() should be run, so pub_date will be filled
 after
 # validation, so the form should save cleanly even though pub_date
 is
 # not allowed to be null.
 data = {
 'title': 'The state of model validation',
 }
 article = Article(author_id=self.author.id)
 form = ArticleForm(data, instance=article)
 self.assertEqual(list(form.errors), [])
 self.assertIsNotNone(form.instance.pub_date)
 article = form.save()
 }}}

 The preface to this test case says developers should be implementing an
 Article.clean(), which looks like this:

 {{{
 def clean(self):
 if self.pub_date is None:
 self.pub_date = datetime.now()
 }}}

 If we run model validation on blankable not-nullable fields, we lose this
 design pattern.

 This is also in agreement with Carlton's assessment
 [https://code.djangoproject.com/ticket/23130#comment:30 here] for
 `BooleanField`:
 > The validation weirdness when blank=True is a red-herring. It causes the
 field to be skipped during full_clean(). At that point developers should
 implementing clean_* to ensure they have an acceptable value. It's quite
 feasible that blank=True doesn't really make sense for a BooleanField, but
 I'm not sure we can tighten it up at this latter stage (no doubt there's
 some use-case…)

 I think the test case at the top demonstrates the use case Carlton was
 reluctant to break for BooleanField, so I'm also reluctant to break it for
 string-based fields.

 But Simon's proposal is another side of the same coin: if you didn't write
 a `clean()`, or your `clean()` missed a case, we could bail you out
 instead of propagating db failures.

 Simon, do you have an opinion about whether your proposal still makes
 sense as a friendly guardrail? If so, then we should do something similar
 for #27697, by providing a nice `{}` if `JSONField` is not nullable.

 #20205 presents a similar set of issues for `PositiveIntegerField`, but I
 think there *is* a fixable change there I plan to submit a patch for
 shortly.

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

Re: [Django] #27697: JSONField with blank=True is rendered as non-required field in a ModelForm

[Django]

#27697: JSONField with blank=True is rendered as non-required field in a 
ModelForm
-+-
 Reporter:  aruseni  |Owner:  Andrew
 |  Nester
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jacob Walls):

 I suggest marking as a duplicate of #4. Any proposal to run model-
 validation on not-nullable blankable fields would fix both (but I suggest
 `wontfix`ing #4 as the status quo represents a supported design
 pattern, will comment there shortly).

 Re: Tim's suggestion:
 > if nothing is submitted, that empty string is transformed into an empty
 dict so it can be saved

 I think this is dangerous because we should preserve the distinction
 between `None` and `{}`, in case the field is nullable. There could be
 code depending on this distinction.

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

Re: [Django] #32927: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU with gdal 3.3.1

[Django]

#32927: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU with
gdal 3.3.1
-+-
 Reporter:  szunami  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by szunami):

 @Mariusz I can still reproduce this issue locally, after having just
 installed django from main. Is this expected?


 {{{
 python
 Python 3.9.6 (default, Jun 28 2021, 19:24:41)
 [Clang 12.0.5 (clang-1205.0.22.9)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import django
 >>> django.get_version()
 '4.0.dev20210719094220'
 >>> from django.contrib.gis.geos import Polygon, MultiPolygon
 >>> MultiPolygon(
 ... Polygon(((-10, 10), (-10, -10), (10, -10), (10, 10), (-10, 10)))
 ... )
 [1]5688 segmentation fault  python3
 }}}

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

Re: [Django] #13883: SelectBox.js with grouping (optgroup elements)

[Django]

#13883: SelectBox.js with grouping (optgroup elements)
-+-
 Reporter:  SardarNL |Owner:  Abhiraj
 |  Chatterjee
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  admin, SelectBox,| Triage Stage:  Accepted
  optgroup, sprintdec2010|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-

Comment (by ᴙɘɘᴙgYmɘᴙɘj):

 Here's a [minimal repro](https://github.com/reergymerej/ticket_13883) for
 anyone who is interested.

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

Re: [Django] #32944: Simplify where clause creation where the WhereNode is immediately created and then added to and then returned.

[Django]

#32944: Simplify where clause creation where the WhereNode is immediately 
created
and then added to and then returned.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * owner:  nobody => Keryn Knight


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

[Django] #32944: Simplify where clause creation where the WhereNode is immediately created and then added to and then returned.

[Django]

#32944: Simplify where clause creation where the WhereNode is immediately 
created
and then added to and then returned.
-+-
   Reporter:  Keryn  |  Owner:  nobody
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  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  |
-+-
 There are currently 2 places in Django which essentially do:
 {{{
 where = WhereNode()
 where.add(condition, AND)
 }}}
 and then return the where.

 There are a ''bunch'' of places where a where class is added to and then
 conditionally added to either immediately or far later in other complex
 branches, (eg: is it a reffed expression, etc). Those are not for
 consideration IMHO because the changes would probably add more complexity.

 But for those 2 places, `django.db.models.sql.query.Query.build_filter`
 and
 `django.contrib.contenttypes.fields.GenericRelation.get_extra_restriction`
 where the code is respectively:
 {{{
 clause = self.where_class()
 clause.add(condition, AND)
 return clause, []
 }}}
 and
 {{{
 cond = where_class()
 lookup = field.get_lookup('exact')(field.get_col(remote_alias),
 contenttype_pk)
 cond.add(lookup, 'AND')
 return cond
 }}}
 both can be simplified to respectively:
 {{{
 return self.where_class([condition], connector=AND), []
 }}}
 and
 {{{
 return where_class([lookup], connector=AND)
 }}}
 which end up as the same result, that is:
 {{{
 x = WhereNode([('a', 1)], connector='AND')
 y = WhereNode()
 y.add(('a', 1), 'AND')
 assert x == y
 }}}
 but a bit faster. Specifically the proposed form is roughly `550-600ns`
 per op vs. the unnecessary add which is `650-700ns`:
 {{{
 In [17]: %%timeit
 ...: x = WhereNode([('a', 1)], connector='AND')
 597 ns ± 12.5 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
 In [18]: %%timeit
 ...: x = WhereNode()
 ...: x.add(('a', 1), 'AND')
 780 ns ± 8.73 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
 }}}
 Given `build_filter` prevalence (it's called what, at least once per
 argument to `filter()` or `exclude()` ... maybe more on complex queries?)
 it's maybe worth having.

 I'll put in a PR shortly to run the bits of the test suite I can't, and
 boil the ocean on the off-chance that this gets accepted. Naturally if
 anything fails, we can just move it to invalid without further
 consideration :)

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

Re: [Django] #23895: ResolverMatch with some views is not pickleable

[Django]

#23895: ResolverMatch with some views is not pickleable
--+
 Reporter:  Keryn Knight  |Owner:  zatro
 Type:  Bug   |   Status:  assigned
Component:  Core (URLs)   |  Version:  4.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 zatro):

 * has_patch:  0 => 1
 * version:  1.7 => 4.0


Comment:

 I've done a fix for this but it might not be the ideal solution. Thoughts?
 If it's okay, please let me know anything the PR is missing.
 [https://github.com/django/django/pull/14664 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.b13c3e83081d4f9b95514da5d67ad970%40djangoproject.com.

Re: [Django] #23895: ResolverMatch with some views is not pickleable

[Django]

#23895: ResolverMatch with some views is not pickleable
--+
 Reporter:  Keryn Knight  |Owner:  zatro
 Type:  Bug   |   Status:  assigned
Component:  Core (URLs)   |  Version:  1.7
 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 zatro):

 * owner:  nobody => zatro
 * 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.36dab6fdf55a41896842f1380de34507%40djangoproject.com.

[Django] #32943: Add support for covering indexes and exclusion constraints for SP-GiST in PostgreSQL 14+.

[Django]

#32943: Add support for covering indexes and exclusion constraints for SP-GiST 
in
PostgreSQL 14+.
-+-
   Reporter:  Nick Pope  |  Owner:  Nick Pope
   Type:  New| Status:  assigned
  feature|
  Component: |Version:  dev
  contrib.postgres   |   Keywords:  postgresql, spgist,
   Severity:  Normal |  index, exclusion, constraint,
   Triage Stage: |  include, covering
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 PostgreSQL 14+ will support covering indexes and exclusion constraints
 using SP-GiST.

 See https://www.postgresql.org/docs/release/14.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/050.b90c1e608973bf18f348d40a7e6954a7%40djangoproject.com.

Re: [Django] #10929: Support a default value for Sum (and possibly other aggregation functions)

[Django]

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
-+-
 Reporter:  nolan|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregate annotate   | Triage Stage:  Ready for
  default|  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/063.3baebb8f02c42081063cfffdc9841e5a%40djangoproject.com.

Re: [Django] #32941: Consider removing unused reverse parameter of utils.formats.get_format_modules

[Django]

#32941: Consider removing unused reverse parameter of
utils.formats.get_format_modules
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"59942a66ceb79868cb91844df3a72a24c63e39fa" 59942a66]:
 {{{
 #!CommitTicketReference repository=""
 revision="59942a66ceb79868cb91844df3a72a24c63e39fa"
 Fixed #32941 -- Removed get_format_modules()'s unused reverse argument.

 Unused since 0d8b523422fda71baa10807d5aebefd34bad7962.
 }}}

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

Re: [Django] #32275: Add scrypt password hasher

[Django]

#32275: Add scrypt password hasher
-+-
 Reporter:  Alex Gaynor  |Owner:  Anthony
 |  Wright
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  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):

 * needs_docs:  1 => 0
 * 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.9a10b8adc6131cc8cfcfe56bc9190e57%40djangoproject.com.