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

[Django]

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

 * 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/063.d62bd5d2ea86e57cf4533c5caa1a49a7%40djangoproject.com.

[Django] #32899: enhance JSONResponse safe=True kwarg docs

[Django]

#32899: enhance JSONResponse safe=True kwarg docs
-+-
   Reporter:  Thomas |  Owner:  Simon Willison
  Grainger   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  3.2
  Documentation  |
   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 JSONResponse documents a `safe` kwarg

 ```
   Data to be dumped into json. By default only ``dict`` objects
   are allowed to be passed due to a security flaw before EcmaScript 5.
 See
   the ``safe`` parameter for more information.
 ```

 EcmaScript 5 is mostly dead, but there are other advantages to only
 sending dicts, see https://twitter.com/simonw/status/1410682522908856320

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

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

[Django]

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

 * 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/063.2df24a081b8573a0ed452a1cb40ba7be%40djangoproject.com.

Re: [Django] #32897: create_user() does not raise ValidationError

[Django]

#32897: create_user() does not raise ValidationError
--+--
 Reporter:  Adam McKay|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  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
--+--

Comment (by Tim Graham):

 I doubt there would be consensus to change the behavior, particularly
 because it could be backward incompatible, but you could try making your
 case on the DevelopersMailingList. The requirements of your use case
 aren't entirely clear, but an alternative could be to use
 `django.contrib.auth.forms.UserCreationForm`.

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

Re: [Django] #32508: Raise proper exceptions instead of using "assert".

[Django]

#32508: Raise proper exceptions instead of using "assert".
--+
 Reporter:  Adam Johnson  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  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
--+

Comment (by Mateo Radman):

 Replying to [comment:29 Mateo Radman]:
 > Thank you very much and apologies for my gendered greeting.
 > I’ll start working on replacing these two asserts.

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

Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Weber):

 I was surprised by this error when trying to upgrade a large codebase to
 3.2. This codebase's convention is to use app labels with dashes, which I
 suspect still works fine (unlike labels with periods).

 Is there a recommended migration path for projects like these that were
 using an invalid label unknowingly? As far as I can tell, the only option
 is to change the label, which looks involved: it affects things like old
 migrations, db rows like content types, and maybe even table names.

 If there's no simple migration path, what about changing this from an
 exception to a warning? That'd still accomplish the goal of informing
 users that something may break and allows cases like mine to avoid quite a
 bit of pain.

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

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

Re: [Django] #32897: create_user() does not raise ValidationError

[Django]

#32897: create_user() does not raise ValidationError
--+--
 Reporter:  Adam McKay|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  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
--+--

Comment (by Adam McKay):

 Replying to [comment:1 Tim Graham]:
 > The lack of validation is consistent with `Model.save()`, etc. I see
 nothing in the documentation that suggests this would behave otherwise.

 Hi Tim,

 I agree the behaviour is consistent with `Model.save()`, however I think
 the usage of `create_user` goes beyond a typical model method as it will
 ensure a `username` is specified (raises an exception if not), normalises
 `username` and `email` and can also generate a `password` if one is not
 specified.

 Perhaps I should have logged this as a feature enhancement to call
 `full_clean()` prior to `user.save()` rather than a bug? My intention
 being to get a more accurate error from the method.

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

Re: [Django] #32840: Micro-optimisation possibility in Field.get_col

[Django]

#32840: Micro-optimisation possibility in Field.get_col
-+-
 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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * has_patch:  0 => 1


Comment:

 PR is here: https://github.com/django/django/pull/14585
 For consistency across 2 separate comment areas:

 The reason I've not opted for the suggested alternative above (and have
 instead kept my rough original proposal) is not a criticism of it, but for
 keeping intent as clear as possible -- the version which was suggested
 relies on the mental parsing of the `x or y` twice (which always causes
 ''me'' to double take) and leaves open an accidental regression in the
 future should someone justify an implementation of `Field.__bool__` which
 is equally/more costly as `Field.__eq__` (I think).

 (Obviously I can change that stance, if it's even deemed worthwhile doing
 it. We'll see)

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

Re: [Django] #32661: An exception should be raised when trying to save an aware datetime/time object even when the UTC offset isn't known.

[Django]

#32661: An exception should be raised when trying to save an aware datetime/time
object even when the UTC offset isn't known.
-+-
 Reporter:  Armin Stepanjan  |Owner:  Abhyudai
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone, datetime,  | Triage Stage:  Accepted
  datetimefield, timefield, models   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Abhyudai):

 * 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/063.76ffd7661b1e2f97e7a94ac1cb076649%40djangoproject.com.

Re: [Django] #32897: create_user() does not raise ValidationError

[Django]

#32897: create_user() does not raise ValidationError
--+--
 Reporter:  Adam McKay|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  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 Tim Graham):

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


Comment:

 The lack of validation is consistent with `Model.save()`, etc. I see
 nothing in the documentation that suggests this would behave otherwise.

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

Re: [Django] #32840: Micro-optimisation possibility in Field.get_col

[Django]

#32840: Micro-optimisation possibility in Field.get_col
-+-
 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:  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
 * 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.db0ffdba81d6cd2532bc7c5aacec2f8d%40djangoproject.com.

Re: [Django] #30934: django.db.backends logging output should include the database alias

[Django]

#30934: django.db.backends logging output should include the database alias
-+-
 Reporter:  David Winterbottom   |Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  logging  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"fa35c8bdbc6aca65d94d6280fa463d5bc7baa5c0" fa35c8bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="fa35c8bdbc6aca65d94d6280fa463d5bc7baa5c0"
 Fixed #30934 -- Included database alias in django.db.backends log
 messages.

 This is useful when working with database routing as you want to know
 where each query is being executed.

 Co-authored-by: David Winterbottom 
 }}}

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

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

Re: [Django] #32892: Optimisation for parse_datetime by preferring datetime.fromisoformat for well-formed values.

[Django]

#32892: Optimisation for parse_datetime by preferring datetime.fromisoformat for
well-formed values.
-+-
 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 Keryn Knight):

 Hey Hasan, absolutely no worries. I was surprised to be in a race (and
 losing!) , but we're all here for the same reason :)

 ---
 For historical note, here's the equivalent timings for `parse_date` and
 `parse_time` with similar (expected) improvements for the happy path:

 Before, using the regex method only. Any and all variants are roughly the
 same 3µs timing
 {{{
 parse_time('00:05:23+04:00')-> 3.56 µs ± 50 ns per loop (mean ± std.
 dev. of 7 runs, 10 loops each)
 parse_time('00:05: ')   -> 3 µs ± 41.3 ns per loop (mean ± std.
 dev. of 7 runs, 10 loops each)
 parse_date('2000-01-01')-> 3.14 µs ± 28.1 ns per loop (mean ± std.
 dev. of 7 runs, 10 loops each)
 }}}

 After, using the regex method as a fallback and the builtin stricter
 format by preference:
 {{{
 parse_time('00:05:23+04:00')-> 1.05 µs ± 2.65 ns per loop (mean ± std.
 dev. of 7 runs, 100 loops each)
 parse_time('00:05: ')   -> 3.66 µs ± 15.2 ns per loop (mean ± std.
 dev. of 7 runs, 10 loops each)
 parse_time('00:05:00')  -> 987 ns ± 6.68 ns per loop (mean ± std.
 dev. of 7 runs, 100 loops each)
 parse_time('00:05:00.001')  -> 1.03 µs ± 12.9 ns per loop (mean ± std.
 dev. of 7 runs, 100 loops each)
 parse_date('2000-01-01')-> 228 ns ± 2.89 ns per loop (mean ± std.
 dev. of 7 runs, 100 loops each
 }}}

 Which handily suggests that the most expensive part of parsing the whole
 iso string is the time+timezone handling, as you might expect.

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

[Django] #32898: get_or_create() with filter() has surprising behaviour

[Django]

#32898: get_or_create() with filter() has surprising behaviour
--+
   Reporter:  Jamie Cockburn  |  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   |
--+
 This documentation:
 https://docs.djangoproject.com/en/3.2/ref/models/querysets/#get-or-create

 That doc says you can combine `filter()` with `get_or_create()`. Great!

 But the resulting behaviour is somewhat surprising.

 Given the following model:
 {{{#!python
 class A(models.Model):
 a = models.CharField()
 b = models.CharField()
 }}}

 I would expect that the following two lines would be fuctionally
 equivalent:
 {{{#!python
 A.objects.get_or_create(a="something", b="another")
 A.objects.filter(a="something").get_or_create(b="another")
 }}}

 If an instance `{"a": "something", "b": "another"}` already exists in the
 database then they ''are'' equivalent.

 If the instance does not exist, the `filter().get_or_create()` version
 will create an instance `{"a": "", "b": "another"}`, throwing away the
 kwargs passed to `filter()`.

 By example:
 {{{#!python
 # create instance
 o, c = A.objects.get_or_create(a='something', b="another")
 print(o.a, o.b, c)

 # find it with filter
 o, c = A.objects.filter(a='something').get_or_create(b="another")
 print(o.a, o.b, c)

 # delete it again
 A.objects.all().delete()

 # create it with filter
 o, c = A.objects.filter(a='something').get_or_create(b="another")
 print(o.a, o.b, c)
 }}}

 Will output:
 {{{
 ('something', 'another', True)
 ('something', 'another', False)
 ('', 'another', True)
 }}}

 This seems rather inconsistent, and should at least be flagged in the
 docs.

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

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

[Django] #32897: create_user() does not raise ValidationError

[Django]

#32897: create_user() does not raise ValidationError
+
   Reporter:  adamckay  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.auth  |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 |
+
 The `django.contrib.auth.models.UserManager.create_user()` function does
 not perform validation checking of the user object prior to saving to the
 database.

 The documentation
 
([https://docs.djangoproject.com/en/3.2/ref/contrib/auth/#django.contrib.auth.models.UserManager.create_user])
 implies this is the canonical way to create a user object and indeed it
 performs functions to normalize the email address and username as well as
 setting an unusable password, however the object is not validated using
 `full_clean()` which results in an object that has validation errors
 attempting to be committed to the database raising an `IntegrityError`
 rather than a `ValidationError`.

 This impacts the ability to add errors to any forms which use
 `create_user()` as the `IntegrityError` does not return a user-friendly
 message, nor is it applied to a field element.

 Reproduction steps in a Django shell:

 {{{
 >>> from django.contrib.auth.models import User
 >>> User.objects.create_user('example')
 
 >>> User.objects.create_user('example')
 Traceback (most recent call last):
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/backends/sqlite3/base.py", line 423, in execute
 return Database.Cursor.execute(self, query, params)
 sqlite3.IntegrityError: UNIQUE constraint failed: auth_user.username

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

 Traceback (most recent call last):
   File "", line 1, in 
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/contrib/auth/models.py", line 152, in create_user
 return self._create_user(username, email, password, **extra_fields)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/contrib/auth/models.py", line 146, in _create_user
 user.save(using=self._db)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/contrib/auth/base_user.py", line 67, in save
 super().save(*args, **kwargs)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/base.py", line 726, in save
 self.save_base(using=using, force_insert=force_insert,
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/base.py", line 763, in save_base
 updated = self._save_table(
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/base.py", line 868, in _save_table
 results = self._do_insert(cls._base_manager, using, fields,
 returning_fields, raw)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/base.py", line 906, in _do_insert
 return manager._insert(
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/query.py", line 1270, in _insert
 return query.get_compiler(using=using).execute_sql(returning_fields)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/models/sql/compiler.py", line 1416, in execute_sql
 cursor.execute(sql, params)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 98, in execute
 return super().execute(sql, params)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 66, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/.pyenv/versions/38-django-core/lib/python3.8/site-
 packages/django/db/utils.py", line 90, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File 

Re: [Django] #28935: Template error raised in an {% extends %} child template shows incorrect source location on debug page

[Django]

#28935: Template error raised in an {% extends %} child template shows incorrect
source location on debug page
-+-
 Reporter:  Matt Westcott|Owner:  cammil
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"313c3d1aa14d80922003f841c257ec4e153f8653" 313c3d1]:
 {{{
 #!CommitTicketReference repository=""
 revision="313c3d1aa14d80922003f841c257ec4e153f8653"
 Fixed #28935 -- Fixed display of errors in extended blocks.

 Get the template that caused the exception and get the
 exception info from that template, using the node that
 caused the exception.
 }}}

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

Re: [Django] #32896: Exclude on expressions not being negated as expected

[Django]

#32896: Exclude on expressions not being negated as expected
-+-
 Reporter:  Alex Henman  |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
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #32398.

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

Re: [Django] #30934: django.db.backends logging output should include the database alias

[Django]

#30934: django.db.backends logging output should include the database alias
-+-
 Reporter:  David Winterbottom   |Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  logging  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * owner:  David Winterbottom => Nick Pope
 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 New [https://github.com/django/django/pull/14584 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/071.aed77bf102d949b111e7d348db884a72%40djangoproject.com.

[Django] #32896: Exclude on expressions not being negated as expected

[Django]

#32896: Exclude on expressions not being negated as expected
-+-
   Reporter:  Alex   |  Owner:  nobody
  Henman |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  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  |
-+-
 Quite similar to #23797 which looks like it was fixed in 3.2.

 Consider the same model definition:

 {{{
 #!python

 from django.db import models

 class Rectangle(models.Model):
 length = models.IntegerField(null=True)
 width = models.IntegerField(null=True)
 }}}

 Then compare the behaviour of excluding when directly accessing the field
 vs. using an alias or annotation:

 {{{
 #!python

 In [5]: str(Rectangle.objects.exclude(length=123).values("pk").query)
 Out[5]: 'SELECT "geometry_rectangle"."id" FROM "geometry_rectangle" WHERE
 NOT ("geometry_rectangle"."length" = 123 AND "geometry_rectangle"."length"
 IS NOT NULL)'

 In [6]:
 
str(Rectangle.objects.alias(aliased_length=F("length")).exclude(aliased_length=123).values("pk").query)
 Out[6]: 'SELECT "geometry_rectangle"."id" FROM "geometry_rectangle" WHERE
 NOT ("geometry_rectangle"."length" = 123)'

 In [7]:
 
str(Rectangle.objects.annotate(aliased_length=F("length")).exclude(aliased_length=123).values("pk").query)
 Out[7]: 'SELECT "geometry_rectangle"."id" FROM "geometry_rectangle" WHERE
 NOT ("geometry_rectangle"."length" = 123)'
 }}}

 The expected behaviour would be that when using an alias or annotation,
 the {{{IS NOT NULL}}} condition would be added when using exclude.

-- 
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/053.3a18abd6dc785472bc567c24ee70d2b5%40djangoproject.com.

Re: [Django] #28935: Template error raised in an {% extends %} child template shows incorrect source location on debug page

[Django]

#28935: Template error raised in an {% extends %} child template shows incorrect
source location on debug page
-+-
 Reporter:  Matt Westcott|Owner:  cammil
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  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/064.a1a4ea1dec038e71456df55bcb1763cd%40djangoproject.com.

Re: [Django] #26430: Coalesce in Aggregations ignored when EmptyResultSet returned

[Django]

#26430: Coalesce in Aggregations ignored when EmptyResultSet returned
-+-
 Reporter:  Ryan Prater  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregation  | Triage Stage:  Ready for
  coalesce in queryset   |  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:"9f3cce172f6913c5ac74272fa5fc07f847b4e112" 9f3cce17]:
 {{{
 #!CommitTicketReference repository=""
 revision="9f3cce172f6913c5ac74272fa5fc07f847b4e112"
 Refs #26430 -- Re-introduced empty aggregation optimization.

 The introduction of the Expression.empty_aggregate_value interface
 allows the compilation stage to enable the EmptyResultSet optimization
 if all the aggregates expressions implement it.

 This also removes unnecessary RegrCount/Count.convert_value() methods.
 Disabling the empty result set aggregation optimization when it wasn't
 appropriate prevented None returned for a Count aggregation value.

 Thanks Nick Pope for the review.
 }}}

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

Re: [Django] #26430: Coalesce in Aggregations ignored when EmptyResultSet returned

[Django]

#26430: Coalesce in Aggregations ignored when EmptyResultSet returned
-+-
 Reporter:  Ryan Prater  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregation  | Triage Stage:  Ready for
  coalesce in queryset   |  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:"f3112fde981052801e0c2121027424496c03efdf" f3112fde]:
 {{{
 #!CommitTicketReference repository=""
 revision="f3112fde981052801e0c2121027424496c03efdf"
 Fixed #26430 -- Fixed coalesced aggregation of empty result sets.

 Disable the EmptyResultSet optimization when performing aggregation as
 it might interfere with coalescence.
 }}}

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

Re: [Django] #32661: An exception should be raised when trying to save an aware datetime/time object even when the UTC offset isn't known.

[Django]

#32661: An exception should be raised when trying to save an aware datetime/time
object even when the UTC offset isn't known.
-+-
 Reporter:  Armin Stepanjan  |Owner:  Abhyudai
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone, datetime,  | Triage Stage:  Accepted
  datetimefield, timefield, models   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Regression in 432678dbc1dd4f80203468d83bb0eb6c20ed5247.

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

Re: [Django] #32661: An exception should be raised when trying to save an aware datetime/time object even when the UTC offset isn't known.

[Django]

#32661: An exception should be raised when trying to save an aware datetime/time
object even when the UTC offset isn't known.
-+-
 Reporter:  Armin Stepanjan  |Owner:  Abhyudai
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone, datetime,  | Triage Stage:  Accepted
  datetimefield, timefield, models   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Re: [Django] #32661: An exception should be raised when trying to save an aware datetime/time object even when the UTC offset isn't known. (was: An exception should be raised when trying to save an aw

[Django]

#32661: An exception should be raised when trying to save an aware datetime/time
object even when the UTC offset isn't known.
-+-
 Reporter:  Armin Stepanjan  |Owner:  Abhyudai
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone, datetime,  | Triage Stage:  Accepted
  datetimefield, timefield, models   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 I double checked,  this issue is more tricky and `DateTimeField`s are also
 affected. `tzinfo` subclasses may not specify the UTC offset (e.g.
 `pytz.timezone("Europe/Paris")`), in such cases we need to also check
 `tzinfo`.

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