Re: [Django] #29026: Make makemigrations scriptable / script-friendly

[Django]

#29026: Make makemigrations scriptable / script-friendly
-+-
 Reporter:  Chris Jerdonek   |Owner:  Jacob
 |  Walls
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  makemigrations,scripting,stderr,stdout|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


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

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

[Django] #33414: Diamond inheritance causes duplicated PK error when creating an object, if the primary key field has a default.

[Django]

#33414: Diamond inheritance causes duplicated PK error when creating an object, 
if
the primary key field has a default.
-+
   Reporter:  Yu Li  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  4.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Hi, I'm not sure if this is a bug or an unsupported feature. But I looked
 into the django/db/models/base.py source code and now have a pretty good
 understanding of what is happening.

 My business code uses a diamond shape inheritance to model different types
 of user posts: UserPost, ImagePost, VideoPost, and MixedContentPost. The
 inheritance goes like this: both ImagePost and VideoPost extend from
 UserPost, and the MixedContentPost inherits from ImagePost and VideoPost.
 All of them are concrete models

 I read the doc and expected it to work, similar to the example


 {{{
 class Piece(models.Model):
 pass

 class Article(Piece):
 article_piece = models.OneToOneField(Piece, on_delete=models.CASCADE,
 parent_link=True)
 ...

 class Book(Piece):
 book_piece = models.OneToOneField(Piece, on_delete=models.CASCADE,
 parent_link=True)
 ...

 class BookReview(Book, Article):
 pass
 }}}

 However, I found out that the doc's example only works when these models
 use a primary key field that does not have a default. In my case, we are
 using a UUIDField as the primary key with a default of uuid4. Trying to
 create a BookReview in our case, causes a django.db.utils.IntegrityError:
 UNIQUE constraint failed error, because django tries to create the Piece
 object twice, with the same uuid.

 The same behavior is found if I used a AutoField on Piece, with a custom
 default function, such as

 {{{
 id = 99

 def increment():
 global id
 id += 1
 return id
 }}}

 This default function makes no sense in practice, but I just use it here
 to illustrate the root cause of the problem:

 The _save_table method in db/models/base.py has a like this:

 {{{
 # Skip an UPDATE when adding an instance and primary key has a
 default.
 if (
 not raw
 and not force_insert
 and self._state.adding
 and meta.pk.default
 and meta.pk.default is not NOT_PROVIDED
 ):
 force_insert = True
 }}}

 When a default is not present, which is the case of the documentation
 example, Django will first insert the first instance of the Piece object,
 and then for the second one, since force_insert is False, _save_table
 tries an update and goes through. Therefore there is not duplicate.

 However, if a default is present, then the second Piece becomes an
 insertion as well (because meta.pk.default and meta.pk.default is not
 NOT_PROVIDED, force_insert is True). This causes a duplication on the
 primary key.

 On the other hand, _insert_parent does an in-order traversal calling
 _save_table on each node, so even in the no-default pk case, it is calling
 a redundant update on the root node after the insertion..

 So which function is at fault?

 The source code _save_table assumes that if you are calling it with a
 default pk then you can skip an update. This assumption looks weird to me:
 why only when there IS a default pk you can skip update? Why not just skip
 update as long as we know we are inserting? (via self._state.adding) Is it
 just to make it special so that AutoField works? If _save_table's
 responsibility is to try updating before inserting, except when the params
 force it to do an update or insert, then it shouldn't override that
 behavior by this self-assumeption  within it.

 I think the solution is to simply move the check to save_base. And don't
 do this check in _save_parents.

 Like this:


 {{{

 def save_base(
 self,
 raw=False,
 force_insert=False,
 force_update=False,
 using=None,
 update_fields=None,
 ):
 """
 Handle the parts of saving which should be done only once per
 save,
 yet need to be done in raw saves, too. This includes some sanity
 checks and signal sending.

 The 'raw' argument is telling save_base not to save any parent
 models and not to do any changes to the values before save. This
 is used by fixture loading.
 """
 using = using or router.db_for_write(self.__class__,
 instance=self)
 assert not (force_insert and (force_update or update_fields))
 assert update_fields is None or update_fields
 cls = origin =

Re: [Django] #33410: captureOnCommitCallbacks executes callbacks multiple times.

[Django]

#33410: captureOnCommitCallbacks executes callbacks multiple times.
-+-
 Reporter:  Petter Friberg   |Owner:  Petter
 |  Friberg
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  captureOnCommitCallbacks   |  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:"bc174e6ea0ce676c5a7f467bda9739e6ef6b6186" bc174e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="bc174e6ea0ce676c5a7f467bda9739e6ef6b6186"
 Fixed #33410 -- Fixed recursive capturing of callbacks by
 TestCase.captureOnCommitCallbacks().

 Regression in d89f976bddb49fb168334960acc8979c3de991fa.
 }}}

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

Re: [Django] #33413: Errors with db_collation – no propagation to foreignkeys

[Django]

#33413: Errors with db_collation – no propagation to foreignkeys
+
 Reporter:  typonaut|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  3.2
 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 Mariusz Felisiak):

 * cc: Tom Carrick (added)


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

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

Re: [Django] #33413: Errors with db_collation – no propagation to foreignkeys

[Django]

#33413: Errors with db_collation – no propagation to foreignkeys
+
 Reporter:  typonaut|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  3.2
 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
+

Old description:

> Using `db_collation` with a `pk` that also has referenced `fk`s in other
> models causes `foreign key constraint` errors in MySQL.
>
> With the following models:
>
> {{{
> class Account(models.Model):
> id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
> db_index=True, max_length=22)
> …
>
> class Address(models.Model):
> id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
> db_index=True, max_length=22)
> account = models.OneToOneField(Account, on_delete=models.CASCADE)
> …
>
> class Profile(models.Model):
> id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
> db_index=True, max_length=22)
> …
> account = models.ForeignKey('Account', verbose_name=_('account'),
> null=True, blank=True, on_delete=models.CASCADE)
> …
>
> etc
> }}}
>
> Where `Account.id` has been changed from `models.BigAutoField` if
> `makemigrations` is run then it produces `sqlmigrate` output like this:
>
> {{{
> ALTER TABLE `b_manage_account` MODIFY `id` varchar(22) COLLATE
> `utf8_bin`;
> ALTER TABLE `b_manage_address` MODIFY `account_id` varchar(22) NOT NULL;
> ALTER TABLE `b_manage_profile` MODIFY `account_id` varchar(22) NULL;
> ALTER TABLE `b_manage_address` ADD CONSTRAINT
> `b_manage_address_account_id_7de0ae37_fk` FOREIGN KEY (`account_id`)
> REFERENCES `b_manage_account` (`id`);
> ALTER TABLE `b_manage_profile` ADD CONSTRAINT
> `b_manage_profile_account_id_ec864dcc_fk` FOREIGN KEY (`account_id`)
> REFERENCES `b_manage_account` (`id`);
> }}}
>
> With this SQL the `ADD CONSTRAINT` queries fail. This is because the
> `COLLATE` should also be present in the `b_manage_address.account_id` and
> `b_manage_profile.account_id` modification statements. Like this:
>
> {{{
> ALTER TABLE `b_manage_account` MODIFY `id` varchar(22) COLLATE
> `utf8_bin`;
> ALTER TABLE `b_manage_address` MODIFY `account_id` varchar(22) NOT NULL
> COLLATE `utf8_bin;
> ALTER TABLE `b_manage_profile` MODIFY `account_id` varchar(22) NULL
> COLLATE `utf8_bin;
> ALTER TABLE `b_manage_address` ADD CONSTRAINT
> `b_manage_address_account_id_7de0ae37_fk` FOREIGN KEY (`account_id`)
> REFERENCES `b_manage_account` (`id`);
> ALTER TABLE `b_manage_profile` ADD CONSTRAINT
> `b_manage_profile_account_id_ec864dcc_fk` FOREIGN KEY (`account_id`)
> REFERENCES `b_manage_account` (`id`);
> }}}
>
> In the latter case the `ADD CONSTRAINT` statements run without error. The
> collation of the `pk` must match the collation of the `fk` otherwise an
> error will occur.

New description:

 Using `db_collation` with a `pk` that also has referenced `fk`s in other
 models causes `foreign key constraint` errors in MySQL.

 With the following models:

 {{{
 class Account(models.Model):
 id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
 db_index=True, max_length=22)
 …

 class Address(models.Model):
 id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
 db_index=True, max_length=22)
 account = models.OneToOneField(Account, on_delete=models.CASCADE)
 …

 class Profile(models.Model):
 id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
 db_index=True, max_length=22)
 …
 account = models.ForeignKey('Account', verbose_name=_('account'),
 null=True, blank=True, on_delete=models.CASCADE)
 …

 etc
 }}}

 Where `Account.id` has been changed from `models.BigAutoField` if
 `makemigrations` is run then it produces `sqlmigrate` output like this:

 {{{
 ALTER TABLE `b_manage_account` MODIFY `id` varchar(22) COLLATE `utf8_bin`;
 ALTER TABLE `b_manage_address` MODIFY `account_id` varchar(22) NOT NULL;
 ALTER TABLE `b_manage_profile` MODIFY `account_id` varchar(22) NULL;
 ALTER TABLE `b_manage_address` ADD CONSTRAINT
 `b_manage_address_account_id_7de0ae37_fk` FOREIGN KEY (`account_id`)
 REFERENCES `b_manage_account` (`id`);
 ALTER TABLE `b_manage_profile` ADD CONSTRAINT
 `b_manage_profile_account_id_ec864dcc_fk` FOREIGN KEY (`account_id`)
 REFERENCES `b_manage_account` (`id`);
 }}}

 With this SQL the `ADD CONSTRAINT` queries fail. This is because the
 `COLLATE` should also be present in the `b_manage_address.account_id` and
 `b_manage_profile.account_id` modification statements. Like this:

 {{{
 ALTER TABLE `b_manage_account` MODIFY `id` varchar(22) COLLATE `utf8_bin`;
 ALTER TABLE `

Re: [Django] #33413: Errors with db_collation – no propagation to foreignkeys

[Django]

#33413: Errors with db_collation – no propagation to foreignkeys
+
 Reporter:  typonaut|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  3.2
 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 Simon Charette):

 * component:  Database layer (models, ORM) => Migrations
 * stage:  Unreviewed => Accepted


Comment:

 
[https://github.com/django/django/blob/806efe912b846c1fde250c9321d8334b7517cd56/django/db/backends/base/schema.py#L217-L219
 It seems like] this should be addressable by defining a
 `ForeignKey.db_collation` property that proxies
 `self.target_field.db_column`

 {{{#!diff
 diff --git a/django/db/models/fields/related.py
 b/django/db/models/fields/related.py
 index 11407ac902..f82f787f5c 100644
 --- a/django/db/models/fields/related.py
 +++ b/django/db/models/fields/related.py
 @@ -1043,6 +1043,10 @@ def db_type(self, connection):
  def db_parameters(self, connection):
  return {"type": self.db_type(connection), "check":
 self.db_check(connection)}

 +@property
 +def db_collation(self):
 +return getattr(self.target_field, 'db_collation', None)
 +
  def convert_empty_strings(self, value, expression, connection):
  if (not value) and isinstance(value, str):
  return None
 }}}

 I do wonder if it would be better to have `'collation': self.db_collation`
 returned in `CharField` and `TextField.db_params` instead and adapt
 `ForeignKey.db_params` to simply proxy `self.target_feld.db_params` and
 adapt the schema editor to branch of `params['collation']` instead as
 `db_collation` is pretty much a ''text fields'' option that ''related
 fields'' should know nothing about.

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

[Django] #33413: Errors with db_collation – no propagation to foreignkeys

[Django]

#33413: Errors with db_collation – no propagation to foreignkeys
-+-
   Reporter:  typonaut   |  Owner:  nobody
   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  |
-+-
 Using `db_collation` with a `pk` that also has referenced `fk`s in other
 models causes `foreign key constraint` errors in MySQL.

 With the following models:

 {{{
 class Account(models.Model):
 id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
 db_index=True, max_length=22)
 …

 class Address(models.Model):
 id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
 db_index=True, max_length=22)
 account = models.OneToOneField(Account, on_delete=models.CASCADE)
 …

 class Profile(models.Model):
 id = ShortUUIDField(primary_key=True, db_collation='utf8_bin',
 db_index=True, max_length=22)
 …
 account = models.ForeignKey('Account', verbose_name=_('account'),
 null=True, blank=True, on_delete=models.CASCADE)
 …

 etc
 }}}

 Where `Account.id` has been changed from `models.BigAutoField` if
 `makemigrations` is run then it produces `sqlmigrate` output like this:

 {{{
 ALTER TABLE `b_manage_account` MODIFY `id` varchar(22) COLLATE `utf8_bin`;
 ALTER TABLE `b_manage_address` MODIFY `account_id` varchar(22) NOT NULL;
 ALTER TABLE `b_manage_profile` MODIFY `account_id` varchar(22) NULL;
 ALTER TABLE `b_manage_address` ADD CONSTRAINT
 `b_manage_address_account_id_7de0ae37_fk` FOREIGN KEY (`account_id`)
 REFERENCES `b_manage_account` (`id`);
 ALTER TABLE `b_manage_profile` ADD CONSTRAINT
 `b_manage_profile_account_id_ec864dcc_fk` FOREIGN KEY (`account_id`)
 REFERENCES `b_manage_account` (`id`);
 }}}

 With this SQL the `ADD CONSTRAINT` queries fail. This is because the
 `COLLATE` should also be present in the `b_manage_address.account_id` and
 `b_manage_profile.account_id` modification statements. Like this:

 {{{
 ALTER TABLE `b_manage_account` MODIFY `id` varchar(22) COLLATE `utf8_bin`;
 ALTER TABLE `b_manage_address` MODIFY `account_id` varchar(22) NOT NULL
 COLLATE `utf8_bin;
 ALTER TABLE `b_manage_profile` MODIFY `account_id` varchar(22) NULL
 COLLATE `utf8_bin;
 ALTER TABLE `b_manage_address` ADD CONSTRAINT
 `b_manage_address_account_id_7de0ae37_fk` FOREIGN KEY (`account_id`)
 REFERENCES `b_manage_account` (`id`);
 ALTER TABLE `b_manage_profile` ADD CONSTRAINT
 `b_manage_profile_account_id_ec864dcc_fk` FOREIGN KEY (`account_id`)
 REFERENCES `b_manage_account` (`id`);
 }}}

 In the latter case the `ADD CONSTRAINT` statements run without error. The
 collation of the `pk` must match the collation of the `fk` otherwise an
 error will occur.

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

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

Re: [Django] #32915: ./manage runserver --nostatic still doesn't return a traceback

[Django]

#32915: ./manage runserver --nostatic still doesn't return a traceback
-+-
 Reporter:  Michael  |Owner:  Rohith P
 |  R
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Rohith P R):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #33410: captureOnCommitCallbacks executes callbacks multiple times.

[Django]

#33410: captureOnCommitCallbacks executes callbacks multiple times.
-+-
 Reporter:  Petter Friberg   |Owner:  Petter
 |  Friberg
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  captureOnCommitCallbacks   |  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/065.fdd9e2ecfd032d1070706d06760d3b06%40djangoproject.com.

Re: [Django] #14586: Make interpolate JS function not require the named parameter.

[Django]

#14586: Make interpolate JS function not require the named parameter.
--+
 Reporter:  Amin Mirzaee  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Internationalization  |  Version:  1.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Baptiste Mispelon):

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


Comment:

 My js knowledge is not super strong but I think what this ticket is asking
 already works.
 In javascript, function parameters are always optional (and default to
 `undefined`).

 The documentation already shows example where `named` is not required:
 https://docs.djangoproject.com/en/4.0/topics/i18n/translation/#interpolate

 There are also tests using `interpolate` without `named`:
 
https://github.com/django/django/blob/806efe912b846c1fde250c9321d8334b7517cd56/tests/view_tests/templates/jsi18n.html#L23

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

Re: [Django] #33400: assertTemplateUsed()/assertTemplateNotUsed() used as context managers ignore count and msg_prefix parameters.

[Django]

#33400: assertTemplateUsed()/assertTemplateNotUsed() used as context managers
ignore count and msg_prefix parameters.
-+-
 Reporter:  karyon   |Owner:  Ad
 |  Timmering
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e700a3714fe668157e5f84ddabfd32d6aac08079" e700a37]:
 {{{
 #!CommitTicketReference repository=""
 revision="e700a3714fe668157e5f84ddabfd32d6aac08079"
 Refs #33400 -- Renamed SimpleTestCase._assert_template_used() to
 _get_template_used().
 }}}

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

Re: [Django] #33400: assertTemplateUsed()/assertTemplateNotUsed() used as context managers ignore count and msg_prefix parameters.

[Django]

#33400: assertTemplateUsed()/assertTemplateNotUsed() used as context managers
ignore count and msg_prefix parameters.
-+-
 Reporter:  karyon   |Owner:  Ad
 |  Timmering
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.0
 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:"806efe912b846c1fde250c9321d8334b7517cd56" 806efe91]:
 {{{
 #!CommitTicketReference repository=""
 revision="806efe912b846c1fde250c9321d8334b7517cd56"
 Fixed #33400 -- Added support for msg_prefix and count arguments to
 assertTemplateUsed()/assertTemplateNotUsed() used as context managers.
 }}}

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

Re: [Django] #32243: Clarify docs on manually setting and saving a FileField.

[Django]

#32243: Clarify docs on manually setting and saving a FileField.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Joshua
 Type:   |  Massover
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 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 Joshua Massover):

 Updated again from more feedback!

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

Re: [Django] #33412: Postgres db backend does not restart connection after disconnect

[Django]

#33412: Postgres db backend does not restart connection after disconnect
-+-
 Reporter:  lijok|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgres db  | 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 #24810 and #30398.

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

Re: [Django] #33400: assertTemplateUsed()/assertTemplateNotUsed() used as context managers ignore count and msg_prefix parameters.

[Django]

#33400: assertTemplateUsed()/assertTemplateNotUsed() used as context managers
ignore count and msg_prefix parameters.
-+-
 Reporter:  karyon   |Owner:  Ad
 |  Timmering
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 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.cc4e8e65e1ad401a5c0c3afae6824e42%40djangoproject.com.

[Django] #33412: Postgres db backend does not restart connection after disconnect

[Django]

#33412: Postgres db backend does not restart connection after disconnect
-+-
   Reporter:  lijok  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  postgres db
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 After a db connection is closed, postgres db backend does not attempt to
 restart it, causing all further queries to fail.


 {{{
 #
 # queries running normally
 #

 2022-01-05 10:38:57.993171 [info ] login request using
 username/password level_number=20 username=ad...@axomic.com
 2022-01-05 10:38:58.070265 [debug] issuing jwt
 claims={'user_uid': 'a12e68b8-2d17-47de-a012-b7d40a979249', 'created':
 '2022-01-05T10:02:12.654683+00:00', 'email': 'ad...@axomic.com',
 'last_logged_in': '2022-01-05T10:38:58.063656+00:00', 'updated':
 '2022-01-05T10:38:58.063677+00:00', 'info': {'admin': True}, 'iat':
 1641379138, 'exp': 1641465538, 'iss': 'localhost', 'admin': True}
 level_number=10
 2022-01-05 10:38:58.096159 [info ] user logged in
 level_number=20 user_email=ad...@axomic.com
 user_uid=a12e68b8-2d17-47de-a012-b7d40a979249

 #
 # db connection is killed
 #

 2022-01-05 10:51:53.020392 [info ] login request using
 username/password level_number=20 username=ad...@axomic.com
 Unexpected [OperationalError] raised by servicer method
 [/axo419.v1.AXO419Service/Login]
 Traceback (most recent call last):
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/django/db/backends/utils.py", line 85, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.OperationalError: terminating connection due to administrator
 command
 server closed the connection unexpectedly
 This probably means the server terminated abnormally
 before or while processing the request.


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

 Traceback (most recent call last):
   File "src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi", line
 680, in grpc._cython.cygrpc._handle_exceptions
   File "src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi", line
 794, in _handle_rpc
   File "src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi", line
 545, in _handle_unary_unary_rpc
   File "src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi", line
 402, in _finish_handler_with_unary_response
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/axomic_python_sdk/grpc/_aio_jwt_authentication_interceptor.py",
 line 130, in new_request_handler
 return await request_handler(request_or_iterator, new_context)
   File
 "/Users/user/repos/AXO419/axo419/api/axo419_v1_service_servicer.py", line
 31, in Login
 token, expires, user = await core.login(
   File "/Users/user/repos/AXO419/axo419/core/auth.py", line 22, in login
 usr = await user.get_user(email=username)
   File "/Users/user/repos/AXO419/axo419/core/user.py", line 75, in
 get_user
 users = await search_users(email=email, first=1)
   File "/Users/user/repos/AXO419/axo419/core/user.py", line 53, in
 search_users
 page = await db.search_users(
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/asgiref/sync.py", line 444, in __call__
 ret = await asyncio.wait_for(future, timeout=None)
   File
 
"/usr/local/Cellar/python@3.10/3.10.0_2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/asyncio/tasks.py",
 line 408, in wait_for
 return await fut
   File
 
"/usr/local/Cellar/python@3.10/3.10.0_2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/concurrent/futures/thread.py",
 line 52, in run
 result = self.fn(*self.args, **self.kwargs)
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/asgiref/sync.py", line 486, in thread_handler
 return func(*args, **kwargs)
   File "/Users/user/repos/AXO419/axo419/db/user.py", line 54, in
 search_users
 page = axomic_python_sdk.pagination.paginate(
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/axomic_python_sdk/pagination/_paginate.py", line 49, in paginate
 page = pagination._limit_pagination.first_pagination(
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/axomic_python_sdk/pagination/_limit_pagination.py", line 12, in
 first_pagination
 total_count = queryset.count()
   File "/Users/user/repos/AXO419/.venv/lib/python3.10/site-
 packages/django/db/models/query.py", line 416, in count
 return self.query.get_count(using=self.db)
   File "/Users/user/repos/A

Re: [Django] #33411: Django 2.2.26 tarball on PyPI differs from djangoproject.org

[Django]

#33411: Django 2.2.26 tarball on PyPI differs from djangoproject.org
---+--
 Reporter:  mbakke |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Packaging  |  Version:  2.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 Carlton Gibson):

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


Comment:

 Yes, as per the metadata, the archives were created separately. As you
 noted they are otherwise identical — specifically they have the tagged
 content for Django 2.2.26 as at 44e7cca62382f2535ed0f5d2842b433f0bd23a57.

 Closing on that basis.

 Nonetheless, is there a particular issue you wanted to highlight? (I can't
 see immediately any concern?)

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

Re: [Django] #33410: captureOnCommitCallbacks executes callbacks multiple times.

[Django]

#33410: captureOnCommitCallbacks executes callbacks multiple times.
-+-
 Reporter:  Petter Friberg   |Owner:  Petter
 |  Friberg
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  captureOnCommitCallbacks   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Petter Friberg):

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

[Django] #33411: Django 2.2.26 tarball on PyPI differs from djangoproject.org

[Django]

#33411: Django 2.2.26 tarball on PyPI differs from djangoproject.org
-+
   Reporter:  mbakke |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Packaging  |Version:  2.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  |
-+
 PyPI is serving a different tarball than djangoproject.org for 2.2.26.

 {{{
 a84c71495d12388ea3e7cb271ba0b6c020e51831477a65e7cd00fe1cce80d103
 Django-2.2.26.tar.gz
 dfa537267d52c6243a62b32855a744ca83c37c70600aacffbfd98bc5d6d8518f
 Django-2.2.26.tar.gz.pypi
 }}}

 The only difference is in gzip compression metadata:

 {{{
 $ file Django-2.2.26.tar.gz*
 Django-2.2.26.tar.gz:  gzip compressed data, was "Django-2.2.26.tar",
 last modified: Tue Jan  4 09:30:26 2022, max compression, original size
 modulo 2^32 52469760
 Django-2.2.26.tar.gz.pypi: gzip compressed data, was "Django-2.2.26.tar",
 last modified: Tue Jan  4 09:40:48 2022, max compression, original size
 modulo 2^32 52469760
 }}}

 The GPG signatures for 2.2.26 on PyPI and djangoproject.org are OK
 however.

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

Re: [Django] #33410: captureOnCommitCallbacks executes callbacks multiple times.

[Django]

#33410: captureOnCommitCallbacks executes callbacks multiple times.
-+-
 Reporter:  Petter Friberg   |Owner:  Petter
 |  Friberg
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  captureOnCommitCallbacks   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_docs:  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.93f5e1802f49d5ce9d48e1e2db6e4cc7%40djangoproject.com.

Re: [Django] #33404: Make `get_elided_page_range` easier to use

[Django]

#33404: Make `get_elided_page_range` easier to use
-+-
 Reporter:  Michael  |Owner:  (none)
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  pagination   | Triage Stage:  Accepted
  paginator page_obj |
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by m_moeinzadeh):

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


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

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

Re: [Django] #33404: Make `get_elided_page_range` easier to use

[Django]

#33404: Make `get_elided_page_range` easier to use
-+-
 Reporter:  Michael  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | Triage Stage:  Accepted
  paginator page_obj |
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by m_moeinzadeh):

 * owner:  m_moeinzadeh => (none)
 * status:  assigned => new


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

Re: [Django] #33404: Make `get_elided_page_range` easier to use

[Django]

#33404: Make `get_elided_page_range` easier to use
-+-
 Reporter:  Michael  |Owner:
 |  m_moeinzadeh
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | Triage Stage:  Accepted
  paginator page_obj |
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by m_moeinzadeh):

 It's impossible to do because in order for `get_elided_page_range` to know
 the page number you need to pass the number to the method directly or pass
 the number inside of paginator object.

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

Re: [Django] #32511: Deferred fields incorrect when following prefetches back to the "parent" object

[Django]

#32511: Deferred fields incorrect when following prefetches back to the "parent"
object
-+-
 Reporter:  Jamie Matthews   |Owner:  Jamie
 |  Matthews
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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:"f5233dce309543c826224be9dfa9c9f4f855f73c" f5233dce]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5233dce309543c826224be9dfa9c9f4f855f73c"
 Fixed #32511 -- Corrected handling prefetched nested reverse
 relationships.

 When prefetching a set of child objects related to a set of parent
 objects, we usually want to populate the relationship back from the
 child to the parent to avoid a query when accessing that relationship
 attribute. However, there's an edge case where the child queryset
 itself specifies a prefetch back to the parent. In that case, we want
 to use the prefetched relationship rather than populating the reverse
 relationship from the parent.
 }}}

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

Re: [Django] #32511: Deferred fields incorrect when following prefetches back to the "parent" object

[Django]

#32511: Deferred fields incorrect when following prefetches back to the "parent"
object
-+-
 Reporter:  Jamie Matthews   |Owner:  Jamie
 |  Matthews
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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):

 * owner:  nobody => Jamie Matthews
 * status:  new => assigned
 * 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.560fcec8acfb1700756266560470c11f%40djangoproject.com.