Re: [Django] #31638: On Mysql/Sqlite, db.models.functions.Now uses wrong timezone

[Django]

#31638: On Mysql/Sqlite, db.models.functions.Now uses wrong timezone
-+-
 Reporter:  Matthijs Kooijman|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 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):

 * cc: Adam (Chainz) Johnson (added)
 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 HI Matthijs. Thanks for the report. Interesting.

 I'm going to close this as needsinfo for now. It's not at all clear to me
 what the correct path is. As such it probably needs some discussion on the
 DevelopersMailingList.
 I'll cc Adam, who know MySQL/MariaDB well enough to speak sensibly.

 A few observations:

 > With sqlite and USE_TZ=True: works, since Now() is in UTC and Django
 defaults to UTC.

 This seems to usual case. That's the one I'd hope would work. (And with
 USE_TZ=True I'm not expecting too much...)

 So contrast with MySQL:

 > With Mysql and USE_TZ=True: fails, since Mysql uses the system timezone
 (UTC+0200) and Django uses UTC.

 Is this not bad behaviour from MySQL, or lacking some config setting? This
 is your "For MySQL, you can change the session timezone (e.g. connection
 timezone)." yes?
 This would seem the most likely avenue to me at the moment.

 Then, I'm not too keen on making `Now` cleverer. The whole point of the
 functions in db.models that they proxy down transparently to what the DB
 provides.

 > For now, I'm going to switch to using timezone.now(),

 I see the intention in using the DB function, but my initial thought
 looking at the test case in the PR was "why not timezone.now() there?".

-- 
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/074.ea4b31277bf999bfe9ec7d469c5c79d6%40djangoproject.com.

Re: [Django] #31630: Replace DatabaseFeatures.introspected_*_field_type attributes with a single attribute.

[Django]

#31630: Replace DatabaseFeatures.introspected_*_field_type attributes with a 
single
attribute.
-+-
 Reporter:  Tim Graham   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 felixxm):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #31656: Help Texts in UserCreationForm cannot be overridden

[Django]

#31656: Help Texts in UserCreationForm cannot be overridden
-+--
 Reporter:  emapall  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  3.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

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


Comment:

 Hi.

 This is expected behaviour. See the **Note** at the bottom of the section
 you linked:

 > ModelForm will only generate fields that are missing from the form, or
 in other words, fields that weren’t defined declaratively.

 The password fields on `UserCreationForm` are declared explicitly. You
 will need to override them in your subclass.

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

Re: [Django] #31650: Mention uniqueness of constraint names in the "name" attribute docs.

[Django]

#31650: Mention uniqueness of constraint names in the "name" attribute docs.
-+-
 Reporter:  Hanne Moa|Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"b80c5baf2936e7b5edfc8055e144e8b2566b047d" b80c5ba]:
 {{{
 #!CommitTicketReference repository=""
 revision="b80c5baf2936e7b5edfc8055e144e8b2566b047d"
 [3.0.x] Fixed #31650 -- Added note uniqueness of constraints names in
 docs.

 Backport of 6e51fb152c864ddc782d9b56e8b785ccf8bc from master
 }}}

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

Re: [Django] #31650: Mention uniqueness of constraint names in the "name" attribute docs.

[Django]

#31650: Mention uniqueness of constraint names in the "name" attribute docs.
-+-
 Reporter:  Hanne Moa|Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"43254876c250a7d470313112cc7750a43ffbd92e" 43254876]:
 {{{
 #!CommitTicketReference repository=""
 revision="43254876c250a7d470313112cc7750a43ffbd92e"
 [3.1.x] Fixed #31650 -- Added note uniqueness of constraints names in
 docs.

 Backport of 6e51fb152c864ddc782d9b56e8b785ccf8bc from master
 }}}

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

Re: [Django] #31650: Mention uniqueness of constraint names in the "name" attribute docs.

[Django]

#31650: Mention uniqueness of constraint names in the "name" attribute docs.
-+-
 Reporter:  Hanne Moa|Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"6e51fb152c864ddc782d9b56e8b785ccf8bc" 6e51]:
 {{{
 #!CommitTicketReference repository=""
 revision="6e51fb152c864ddc782d9b56e8b785ccf8bc"
 Fixed #31650 -- Added note uniqueness of constraints names in 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/062.a90204200fecafdf7660c1288392a6a1%40djangoproject.com.

Re: [Django] #31658: Performing SQL queries in AppConfig.ready(). (was: [POSSIBLE FEATURE REQUEST] Additional Django lifecycle methods?)

[Django]

#31658: Performing SQL queries in AppConfig.ready().
-+-
 Reporter:  Ying Wang|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  database,| Triage Stage:
  migrations, lifecycle, hooks   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Migrations => Core (Other)


Comment:

 Database operations shouldn't be performed at module loading time, you can
 find a warning in
 
[https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.ready
 AppConfig.ready() docs] (see related #30424). We don't want to encourage
 user to do this.

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

Re: [Django] #31657: Self referencing foreign key doesn't correctly order by a relation "_id" field.

[Django]

#31657: Self referencing foreign key doesn't correctly order by a relation "_id"
field.
-+-
 Reporter:  Jack Delany  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (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
-+-

Comment (by Jack Delany):

 FWIW, I did apply the suggested fix to my local version and I do now get
 what looks like correct behavior and results that match what Simon
 suggested should be the sort results.  Also my annotate "workaround"
 continues to behave correctly.   Looks promising.

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

Re: [Django] #31657: self referencing foreign key join and order_by issues

[Django]

#31657: self referencing foreign key join and order_by issues
---+--
 Reporter:  Jack Delany|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 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
---+--

Comment (by Simon Charette):

 Something is definitely wrong here.

 - `order_by('record__root_id')` should result in `ORDER BY root_id`
 - `order_by('record__root')` should use the `Meta.ordering` in `ORDER BY
 root_join.id DESC`
 
[https://docs.djangoproject.com/en/3.0/ref/models/querysets/#django.db.models.query.QuerySet.order_by
 as documented]
 - `order_by('record__root__id')` should result in `ORDER BY root_join.id`

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

[Django] #31657: self referencing foreign key join and order_by issues

[Django]

#31657: self referencing foreign key join and order_by issues
-+
   Reporter:  Jack Delany|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 Initially discovered on 2.2.10 but verified still happens on 3.0.6.  Given
 the following models:
 {{{
 class OneModel(models.Model):
 class Meta:
 ordering = ("-id",)

 id = models.BigAutoField(primary_key=True)
 root = models.ForeignKey("OneModel", on_delete=models.CASCADE,
 null=True)
 oneval = models.BigIntegerField(null=True)

 class TwoModel(models.Model):
 id = models.BigAutoField(primary_key=True)
 record = models.ForeignKey(OneModel, on_delete=models.CASCADE)
 twoval = models.BigIntegerField(null=True)
 }}}
 The following queryset gives unexpected results and appears to be an
 incorrect SQL query:
 {{{
 qs = TwoModel.objects.filter(record__oneval__in=[1,2,3])
 qs = qs.order_by("record__root_id")
 print(qs.query)
 }}}
 {{{
 SELECT "orion_twomodel"."id", "orion_twomodel"."record_id",
 "orion_twomodel"."twoval" FROM "orion_twomodel" INNER JOIN
 "orion_onemodel" ON ("orion_twomodel"."record_id" = "orion_onemodel"."id")
 LEFT OUTER JOIN "orion_onemodel" T3 ON ("orion_onemodel"."root_id" =
 T3."id") WHERE "orion_onemodel"."oneval" IN (1, 2, 3) ORDER BY T3."id"
 DESC
 }}}
 The query has an unexpected DESCENDING sort.  That appears to come from
 the default sort order on the OneModel class, but I would expect the
 order_by() to take prececence.  The the query has two JOINS, which is
 unnecessary.  It appears that, since OneModel.root is a foreign key to
 itself, that is causing it to do the unnecessary extra join.  In fact,
 testing a model where root is a foreign key to a third model doesn't show
 the problem behavior.

 Note also that the queryset with `order_by("record__root")` gives the
 exact same SQL.

 This queryset gives correct results and what looks like a pretty optimal
 SQL:
 {{{
 qs = TwoModel.objects.filter(record__oneval__in=[1,2,3])
 qs = qs.order_by("record__root__id")
 print(qs.query)
 }}}
 {{{
 SELECT "orion_twomodel"."id", "orion_twomodel"."record_id",
 "orion_twomodel"."twoval" FROM "orion_twomodel" INNER JOIN
 "orion_onemodel" ON ("orion_twomodel"."record_id" = "orion_onemodel"."id")
 WHERE "orion_onemodel"."oneval" IN (1, 2, 3) ORDER BY
 "orion_onemodel"."root_id" ASC
 }}}

 So is this a potential bug or a misunderstanding on my part?

 Another queryset that works around the issue and gives a reasonable SQL
 query and expected results:
 {{{
 qs = TwoModel.objects.filter(record__oneval__in=[1,2,3])
 qs = qs.annotate(root_id=F("record__root_id"))
 qs = qs.order_by("root_id")
 print(qs.query)
 }}}
 {{{
 SELECT "orion_twomodel"."id", "orion_twomodel"."record_id",
 "orion_twomodel"."twoval" FROM "orion_twomodel" INNER JOIN
 "orion_onemodel" ON ("orion_twomodel"."record_id" = "orion_onemodel"."id")
 WHERE "orion_onemodel"."oneval" IN (1, 2, 3) ORDER BY
 "orion_onemodel"."zero_id" ASC
 }}}
 ASCENDING sort, and a single INNER JOIN, as I'd expect.  That actually
 works for my use because I need that output column anyway.

 One final oddity; with the original queryset but the inverted sort
 order_by():
 {{{
 qs = TwoModel.objects.filter(record__oneval__in=[1,2,3])
 qs = qs.order_by("-record__root_id")
 print(qs.query)
 }}}
 {{{
 SELECT "orion_twomodel"."id", "orion_twomodel"."record_id",
 "orion_twomodel"."twoval" FROM "orion_twomodel" INNER JOIN
 "orion_onemodel" ON ("orion_twomodel"."record_id" = "orion_onemodel"."id")
 LEFT OUTER JOIN "orion_onemodel" T3 ON ("orion_onemodel"."root_id" =
 T3."id") WHERE "orion_onemodel"."oneval" IN (1, 2, 3) ORDER BY T3."id" ASC
 }}}
 One gets the query with the two JOINs but an ASCENDING sort order.  I was
 not under the impression that sort orders are somehow relative to the
 class level sort order, eg: does specifing `order_by("-record__root_id")`
 invert the class sort order?  Testing that on a simple case doesn't show
 that behavior at all.

 Thanks for any assistance and clarification.

-- 
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

Re: [Django] #31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT

[Django]

#31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE
CONSTRAINT
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  master
 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 Adam (Chainz) Johnson):

 > I'd suggest we document breaking the operations in two migrations
 instead of using atomic=False otherwise your database will be left in a
 inconsistent state if the ValidateConstraint operation fails.

 Yes. I think MySQL has made me reach for `atomic = False` too much 😂

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

Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
-+
 Reporter:  Sergey Fedoseev  |Owner:  Zorking
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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 Zorking):

 * owner:  (none) => Zorking
 * 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/068.8793d84b54206e002651debea9e98805%40djangoproject.com.

Re: [Django] #31655: Development server quits on request to /admin/ (was: Development Server Quits on Request to /admin/)

[Django]

#31655: Development server quits on request to /admin/
---+--
 Reporter:  kormanowsky|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  3.0
 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
---+--

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

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

Re: [Django] #31654: Memcached key validation raises InvalidCacheKey with clunky message. (was: Memcached key validation raises TypeError on invalid characters)

[Django]

#31654: Memcached key validation raises InvalidCacheKey with clunky message.
-+
 Reporter:  Tim McCormack|Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  memcached| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

 * owner:  nobody => felixxm
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report, we've already noticed this, see
 [https://github.com/django/django/pull/13017 PR]. It raises
 `InvalidCacheKey` for me (even if a message is not perfect), e.g.
 {{{
 File "django/core/cache/backends/memcached.py", line 157, in validate_key
 raise InvalidCacheKey(warning)

 django.core.cache.backends.base.InvalidCacheKey: ("Cache key contains
 characters that will cause errors if used with memcached:
 '38_postgis_pull-requests-bionic_memcache:1:key with spaces and 清'",
 )
 }}}

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

Re: [Django] #20347: Add an absolute_max parameter to formset_factory

[Django]

#20347: Add an absolute_max parameter to  formset_factory
---+---
 Reporter:  Carsten Fuchs  |Owner:  David Smith
 Type:  New feature|   Status:  assigned
Component:  Forms  |  Version:  master
 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 David Smith):

 * needs_better_patch:  1 => 0


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

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

[Django] #31654: Memcached key validation raises TypeError on invalid characters

[Django]

#31654: Memcached key validation raises TypeError on invalid characters
---+---
   Reporter:  Tim McCormack|  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (Cache system)  |Version:  2.2
   Severity:  Normal   |   Keywords:  memcached
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 On Django 2.2.13 the code for `memcache_key_warnings` in
 `django/core/cache/backends/base.py` has a bad format string that results
 in raising an exception rather than just producing a warning. This can be
 reproduced with a memcached key with a space in it, e.g. `"foo bar"`.

 This code was present before the 2.2.13 release, but becomes more exposed
 with that release, since it begins validating cache keys.

 I think it's as simple as removing the `, CacheKeyWarning`.

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

Re: [Django] #31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT

[Django]

#31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE
CONSTRAINT
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  master
 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):

 * stage:  Unreviewed => Accepted


Comment:

 > I think custom django.contrib.postgres operations would be the way. They
 can document to use non-atomic migrations. Rather than AddConstraint(...,
 validate=False) I'd suggest AddConstraintNotValid(...) as a subclass of
 AddConstraint, and ValidateConstraint.

 I think that's the way to go as well. I'd suggest we document breaking the
 operations in two migrations instead of using `atomic=False` otherwise
 your database will be left in a inconsistent state if the
 `ValidateConstraint` operation fails.

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

Re: [Django] #31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT (was: PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT)

[Django]

#31653: Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE
CONSTRAINT
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  master
 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 Adam (Chainz) Johnson):

 * component:  Migrations => contrib.postgres


Old description:

> If you read the ALTER TABLE PostgreSQL docs (
> https://www.postgresql.org/docs/12/sql-altertable.html ) for `ADD
> CONSTRAINT`, you'll see that it supports the `NOT VALID` option. This
> prevents the constraint from being checked against all existing data,
> although it does affect all inserted/updated rows. Adding a constraint
> this way does not exclusively lock the whole table to check it. To
> promote it to valid, the `VALIDATE CONSTRAINT` syntax can be used. This
> allows a non-exclusive lock on the table to validate all existing rows.
> This two step techinque allows constraints to be added to very active
> tables without locking out concurrent access and thus inflicting
> downtime.
>
> I suggest Django always use this form when adding foreign keys and check
> constraints.

New description:

 If you read the ALTER TABLE PostgreSQL docs (
 https://www.postgresql.org/docs/12/sql-altertable.html ) for `ADD
 CONSTRAINT`, you'll see that it supports the `NOT VALID` option. This
 prevents the constraint from being checked against all existing data,
 although it does affect all inserted/updated rows. Adding a constraint
 this way does not exclusively lock the whole table to check it. To promote
 it to valid, the `VALIDATE CONSTRAINT` syntax can be used. This allows a
 non-exclusive lock on the table to validate all existing rows. This two
 step techinque allows constraints to be added to very active tables
 without locking out concurrent access and thus inflicting downtime.

 I suggest `django.contrib.postgres` add custom operations for these
 commands, with appropriate documentation around using them in non-atomic
 migrations.

--

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

Re: [Django] #31653: PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT

[Django]

#31653: PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 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
-+-

Comment (by Adam (Chainz) Johnson):

 > My interpretation is that in order for other transactions to see that
 the constraint was added in a READ COMMITTED scenario the ADD CONSTRAINT
 NOT VALID must be committed first; performing a ADD CONSTRAINT NOT VALID
 and VALIDATE CONSTRAINT in the same transaction should result in the same
 operations as ADD CONSTRAINT otherwise PostgreSQL would always do it by
 default?

 Yes... the one time I've used `NOT VALID` was actually in an `atomic =
 False` migration so I didn't test it with atomic. I was probably too
 zealous reading the PostgreSQL docs which don't mention transactions.

 I think custom `django.contrib.postgres` operations would be the way. They
 can document to use non-atomic migrations. Rather than `AddConstraint(...,
 validate=False)` I'd suggest `AddConstraintNotValid(...)` as a subclass of
 `AddConstraint`, and `ValidateConstraint`.

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

Re: [Django] #31626: Add asgi support to runserver

[Django]

#31626: Add asgi support to runserver
-+
 Reporter:  Joshua Massover  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  runserver, asgi  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carlton Gibson):

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


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

Re: [Django] #31626: Add asgi support to runserver

[Django]

#31626: Add asgi support to runserver
-+-
 Reporter:  Joshua Massover  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  runserver, asgi  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * keywords:   => runserver, asgi
 * component:  Uncategorized => HTTP handling
 * stage:  Unreviewed => Accepted


Comment:

 OK, let's accept this as a new feature.

 The suggestion in the forum thread is to detect if Daphne or uvicorn or
 ... is installed and then use that.

 In the draft PR looks like importing Daphne in a `try` block, which I´m
 not sure about at all.
 Is there a way we can detect the asgi server without hard-coding imports?

 I'd imagined a server based off of Python's `http.server`, as we have for
 WSGI, either in Django or `asigref` as appropriate.


 In the meantime, 3.1 could probably do with some docs, saying to install
 channels (to use it's runserver) or uvicorn (which has a `--reload`
 option).

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

Re: [Django] #29789: Support nested relations in FilteredRelation's condition

[Django]

#29789: Support nested relations in FilteredRelation's condition
-+-
 Reporter:  Thomas Riccardi  |Owner:  Matt
 |  Ferrante
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  FilteredRelation | Triage Stage:  Accepted
  nested relations   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matt Ferrante):

 I've been using a branch with this patch for nested FilteredRelations in
 production for 4 months without issues. It works really well and added a
 lot of flexibility and allowed for performance optimizations which helped
 with our analytical query speed. Hoping this gets approved and changes to
 "Ready for checkin" soon!

-- 
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/073.bb0432ab41d0f195a6590ed6c7291a10%40djangoproject.com.

Re: [Django] #31641: Admin Sidebar flashes when page loads

[Django]

#31641: Admin Sidebar flashes when page loads
-+-
 Reporter:  Collin Anderson  |Owner:  Collin
 |  Anderson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Release blocker  |   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:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"4ae9a2b18e2b558df2c084064c42faecac2d75c1" 4ae9a2b1]:
 {{{
 #!CommitTicketReference repository=""
 revision="4ae9a2b18e2b558df2c084064c42faecac2d75c1"
 Fixed #31641 -- Improved loading of navigation sidebar in admin.
 }}}

-- 
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/072.033f638989b8c9ac0168552a4c113499%40djangoproject.com.

Re: [Django] #31645: Models have changes red alert message should say which apps/models

[Django]

#31645: Models have changes red alert message should say which apps/models
--+
 Reporter:  John Vandenberg   |Owner:  Chinmoy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 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 Chinmoy):

 * Attachment "mod_out.png" added.

 Test output of pending migrations

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

Re: [Django] #31641: Admin Sidebar flashes when page loads

[Django]

#31641: Admin Sidebar flashes when page loads
-+-
 Reporter:  Collin Anderson  |Owner:  Collin
 |  Anderson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Release blocker  |   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:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"5b3886d091008361d2a05329acd7b51b91a8fdde" 5b3886d0]:
 {{{
 #!CommitTicketReference repository=""
 revision="5b3886d091008361d2a05329acd7b51b91a8fdde"
 [3.1.x] Fixed #31641 -- Improved loading of navigation sidebar in admin.

 Backport of 4ae9a2b18e2b558df2c084064c42faecac2d75c1 from master
 }}}

-- 
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/072.b017818de58cbb81df2e7041bcdc3bb6%40djangoproject.com.

Re: [Django] #31650: Mention uniqueness of constraint names in the "name" attribute docs.

[Django]

#31650: Mention uniqueness of constraint names in the "name" attribute docs.
-+-
 Reporter:  Hanne Moa|Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

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

Re: [Django] #31645: Models have changes red alert message should say which apps/models

[Django]

#31645: Models have changes red alert message should say which apps/models
--+
 Reporter:  John Vandenberg   |Owner:  Chinmoy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 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 Chinmoy):

 I think a message similar to that given by **makemigrations --dry-run**
 would be good enough?

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

Re: [Django] #31653: PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT

[Django]

#31653: PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 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
-+-

Comment (by Simon Charette):

 The documentation states

 > After that, a VALIDATE CONSTRAINT command can be issued to verify that
 existing rows satisfy the constraint. The validation step does not need to
 lock out concurrent updates, since it knows that other transactions will
 be enforcing the constraint for rows that they insert or update; only pre-
 existing rows need to be checked.

 My interpretation is that in order for other transactions to ''see'' that
 the constraint was added in a `READ COMMITTED` scenario the `ADD
 CONSTRAINT NOT VALID` must be committed first; performing a `ADD
 CONSTRAINT NOT VALID` and `VALIDATE CONSTRAINT` in the same transaction
 should result in the same operations as `ADD CONSTRAINT` otherwise
 PostgreSQL would always do it by default?

 I could be missing something as I didn't try it out locally but from my
 understanding this would need the following set of migrations to be
 generated to work properly.

 {{{#!python
 class Migration(migrations.Migration):
 operations = [
 AddConstraint(Constraint(name='foo'), validate=False),
 ]

 class Migration(migrations.Migration):
 operations = [
 ValidateConstraint('foo'),
 ]
 }}}

 Running the first migration would commit the `ADD CONSTRAINT NOT VALID`
 and allow other transactions to start enforcing it which is something the
 `VALIDATE CONSTRAINT` could assume in the following transaction.

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

Re: [Django] #17613: Add validation method for cache keys

[Django]

#17613: Add validation method for cache keys
-+
 Reporter:  Vlastimil Zíma   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carlton Gibson):

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


Comment:

 Since 2c82414914ae6476be5a166be9ff49c24d0d9069 the memcached backends
 validate keys, in line with the other backends.

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

Re: [Django] #31610: Make it easier to override the RelatedFieldWidgetWrapper in admin.

[Django]

#31610: Make it easier to override the RelatedFieldWidgetWrapper in admin.
-+-
 Reporter:  rm_  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rm_):

 * cc: rm_ (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/061.5fe00c72bd4503faea0eff7dc57e84f3%40djangoproject.com.

Re: [Django] #23048: Add the ability to make RemoveField reversible for non-null fields

[Django]

#23048: Add the ability to make RemoveField reversible for non-null fields
-+
 Reporter:  Harris Lapiroff  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7-rc-1
 Severity:  Normal   |   Resolution:  wontfix
 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 rm_):

 * cc: rm_ (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/072.df95017ec99d8999281daa3f384f90c3%40djangoproject.com.

Re: [Django] #31632: Single queries without transaction do not follow AUTOCOMMIT

[Django]

#31632: Single queries without transaction do not follow AUTOCOMMIT
-+-
 Reporter:  Filipe Pina  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 Florian Apolloner):

 * version:  2.2 => master
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


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

Re: [Django] #31632: Single queries without transaction do not follow AUTOCOMMIT

[Django]

#31632: Single queries without transaction do not follow AUTOCOMMIT
-+-
 Reporter:  Filipe Pina  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.2
  (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 Florian Apolloner):

 * cc: Adam (Chainz) Johnson (added)


Comment:

 > I don't usually run with MySQL (PG favorite choice), so I don't know how
 often these sort of bugs come up or how you tackle them.

 Same here, so I'll defer to our MySQL users on how to handle this. Adding
 Adam since he is also a heavy MySQL user. I am fine with fixing it in
 Django and/or mysqlclient but I will not write the code for it.

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

Re: [Django] #23048: Add the ability to make RemoveField reversible for non-null fields

[Django]

#23048: Add the ability to make RemoveField reversible for non-null fields
-+
 Reporter:  Harris Lapiroff  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7-rc-1
 Severity:  Normal   |   Resolution:  wontfix
 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 rm_):

 Found this debugging a similar issue. My problem comes from having some
 migrations tests that test a specific migrations for a field that I'm
 trying to remove. So in my migrations history I have: addfield -> make
 nullable -> remove field

 I've tried to add a default as suggested above:

 -field=models.ForeignKey(blank=True, null=True,
 on_delete=django.db.models.deletion.CASCADE,
 to='translatable_messages.Language'),
 +field=models.ForeignKey(blank=True, null=True,
 on_delete=django.db.models.deletion.CASCADE,
 to='translatable_messages.Language', default=1),
 +preserve_default=False

 but instead of postgres warning about the field having null values when
 it's not supposed to i get this:

 django.db.utils.OperationalError: cannot ALTER TABLE
 "translatable_messages_translatablemessage" because it has pending trigger
 events

 I'm tempted to remove the tests on the migrations and call it a day but
 maybe there's something else I can do?

-- 
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/072.fb3e9375afa387a42f07082ff892d491%40djangoproject.com.

Re: [Django] #31641: Admin Sidebar flashes when page loads

[Django]

#31641: Admin Sidebar flashes when page loads
-+-
 Reporter:  Collin Anderson  |Owner:  Collin
 |  Anderson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.1
 Severity:  Release blocker  |   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:  1
-+-
Changes (by felixxm):

 * 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/072.5a8809e57216d02447c6858dc660f4ab%40djangoproject.com.

Re: [Django] #31610: Make it easier to override the RelatedFieldWidgetWrapper in admin.

[Django]

#31610: Make it easier to override the RelatedFieldWidgetWrapper in admin.
-+-
 Reporter:  rm_  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rm_):

 Sorr for the late response but I didn't get any notification. The plan is
 to use a custom widget, the patches here are 1) a way to use a custom
 widget without overriding the full BaseModelAdmin.formfield_for_dbfield
 becasue RelatedFieldWidgetWrapper is hardcoded 2)  extract a simpler
 method in RelatedFieldWidgetWrapper to override (that also matches what
 the other related widgets are doing). Anyway I don't want to insist,
 thanks anyway 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/061.27aa9f2570d6e3f1b1103c849b41ca2c%40djangoproject.com.