Re: [Django] #33515: ManyToManyField to lowercased swappable setting causes generating infinite migrations.

[Django]

#33515: ManyToManyField to lowercased swappable setting causes generating 
infinite
migrations.
-+-
 Reporter:  Chris Lee|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  M2M migration user   | Triage Stage:  Accepted
  manytomany |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * 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/070.59b39b8a673507dbc72965291c0187c8%40djangoproject.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by elonzh):

 * cc: elonzh (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/063.3af797675402edf6e270bde48be0f393%40djangoproject.com.

Re: [Django] #33505: Inconsistent Behavior with Abstract Models and Signals

[Django]

#33505: Inconsistent Behavior with Abstract Models and Signals
-+-
 Reporter:  Ken Weaver   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:6 Ken Weaver]:
 > I now understand why; I just checked and `Abstract.m2m_field.through`
 itself is actually `None`. This makes sense (somewhat) since of course you
 can't have a concrete many to many table for an abstract model.

 Ahh, yes. You can set `sender` to `None` to receive events from any
 sender.

 > I would think one could change `ManyToManyField` to itself be some kind
 of abstract model or a dummy class when attached to an abstract model, but
 you will know more about the inners of Django to know if something like
 that is feasible or justified.

 I don't think it is feasible.

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

Re: [Django] #33516: QuerySet update() under postgres with select_for_update(skip_locked=True) results in neither FOR UPDATE nor SKIP LOCKED

[Django]

#33516: QuerySet update() under postgres with 
select_for_update(skip_locked=True)
results in neither FOR UPDATE nor SKIP LOCKED
-+-
 Reporter:  Grant Gainey |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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 Simon Charette):

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


Comment:

 In the latest version of Django
 
[https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/db/models/sql/query.py#L2161-L2171
 the ordering should not be cleared] when `select_for_update` is used on
 the subquery provided to a `__in` lookup.


 {{{#!python
 def update_timestamp(index):
 content_q = (
 TestModel.objects.order_by("pk")
 .select_for_update(skip_locked=True)
 .values_list("pk", flat=True)
 )
 TestModel.objects.filter(pk__in=content_q).update(timestamp_of_interest=now())
 }}}

 There was some recent changes in this area in 4.0 and I haven't confirmed
 if this is an issue on 3.2 but in all cases `order_by.select_for_update`
 has to be called on the subquery and not the outer one for this to work as
 the resulting SQL hints at and that's likely why your solution isn't
 working here.

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

[Django] #33516: QuerySet update() under postgres with select_for_update(skip_locked=True) results in neither FOR UPDATE nor SKIP LOCKED

[Django]

#33516: QuerySet update() under postgres with 
select_for_update(skip_locked=True)
results in neither FOR UPDATE nor SKIP LOCKED
-+-
   Reporter:  Grant  |  Owner:  nobody
  Gainey |
   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  |
-+-
 === Versions:
 {{{
 $ cat /etc/fedora-release
 Fedora release 34 (Thirty Four)

 $ pip freeze | grep -i django
 Django==3.2.12
 django-crispy-forms==1.13.0
 django-currentuser==0.5.3
 django-extensions==3.1.5
 django-filter==21.1
 django-guardian==2.4.0
 django-guid==3.2.1
 django-import-export==2.7.1
 django-lifecycle==0.9.3
 django-readonly-field==1.1.1
 django-storages==1.12.3
 djangorestframework==3.13.1
 djangorestframework-queryfields==1.0.0

 $ psql --version
 psql (PostgreSQL) 13.4
 }}}

 === Problem Statement
 pulpcore is a Django app that does A Lot Of Concurrent Stuff. One of those
 Things includes "update the last-touched timestamp of large batches of
 entities at the end of a workflow". We use
 `queryset.update(timestamp_of_interest=now())` for this.

 Batch updates don't guarantee row-update-order in Postgresql. In heavy-
 concurrency contexts, when updating overlapping content in multiple
 threads, this can result in deadlocks as postgres acquires row-locks in
 arbitrary orders.

 To get around this, in raw postgres, one uses `UPDATE...WHERE id IN
 (SELECT  id FROM table WHERE expression ORDER BY id FOR UPDATE)`. The
 SELECT-FOR-UPDATE-ORDER-BY enforces row-lock-ordering prior to the UPDATE,
 and everyone is happily synchronized and all the dining philosophers get
 to eat.

 If (as in our specific use-case) you don't actually care **who** updates
 the row, just that it is being updated "now()-ish", you can regain some
 concurrency by using Postgres' `SKIP LOCKED` functionality.

 So - we attempted to use the following to accomplish that in our update
 workflow:
 {{{
 TestModel.objects.filter(pk__in=content_q).order_by("pk").select_for_update(
 skip_locked=True
 ).update(timestamp_of_interest=now())
 }}}

 By the time we get to Postgres, this **does not emit FOR UPDATE or SKIP
 LOCKED**, and therefore doesn't solve our deadlock problem. Cue sad-
 trombone.

 Specifically, from the driver-example below, this code:
 {{{
 def update_timestamp(index):
 content_q = (
 TestModel.objects.filter()
 .order_by("pk")
 .values_list("pk", flat=True)
 )
 TestModel.objects.filter(pk__in=content_q).order_by("pk").select_for_update(
 skip_locked=True
 ).update(timestamp_of_interest=now())
 }}}

 generates this SQL:
 {{{
 2022-02-15 19:12:47.276 UTC [337361] LOG:  statement: UPDATE
 "core_testmodel" SET "timestamp_of_interest" =
 '2022-02-15T19:12:47.187475+00:00'::timestamptz WHERE
 "core_testmodel"."pulp_id" IN (SELECT U0."pulp_id" FROM "core_testmodel"
 U0)
 }}}

 Running the driver-example will generate deadlocks; the more TestModel
 entries exist, the more often you hit a deadlock. With 5K entries, test
 runs hit deadlocks ~5-10 times. With 20K entries, it was more like ~60-70%
 of the 100 runs.

 === Workaround
 Right now, we implemented a workaround in raw SQL. You can see it here:

 https://github.com/pulp/pulpcore/pull/2159/files#diff-
 81f6a78175bb93934b6beff952646d3ca1ef3731f1ff14492d4ec77bfc3fdf82R132-R141

 We would **much much rather** not have to use raw-sql.

 === Full Example:

 * Here's a really simple model, stored as `pulpcore/apps/models/test.py`
 {{{
 import uuid
 from django.db import models
 from django_lifecycle import LifecycleModel


 class TestModel(LifecycleModel):
 pulp_id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 timestamp_of_interest = models.DateTimeField(auto_now=True)
 }}}

 * Here's a migration that creates that model:
 {{{
 # Generated by Django 3.2.12 on 2022-02-15 18:53

 from django.db import migrations, models
 import django_lifecycle.mixins
 import uuid


 class Migration(migrations.Migration):

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='TestModel',
 fields=[
 ('pulp_id', models.UUIDField(default=uuid.uuid4,
 editable=False, primary_key=True, serialize=False)),
 ('timestamp_of_interest',
 models.DateTimeField(auto_now=True)),
 ],
 options={
 'abstract': False,
 },
 bas

Re: [Django] #33405: Documentation for template filter 'escapejs' is extremely unclear

[Django]

#33405: Documentation for template filter 'escapejs' is extremely unclear
-+-
 Reporter:  Jon Ribbens  |Owner:  Jon
 Type:   |  Ribbens
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Carlton Gibson):

 * 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/066.3c9deeb36fd212907bb8e946613b621f%40djangoproject.com.

Re: [Django] #33505: Inconsistent Behavior with Abstract Models and Signals

[Django]

#33505: Inconsistent Behavior with Abstract Models and Signals
-+-
 Reporter:  Ken Weaver   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ken Weaver):

 Yes it seemed very strange to me too, I thought the signal should be
 received either when an inherited model's `ManyToManyField` changed (this
 was my mistake) or not at all. But instead it is received for every
 `m2m_changed`, even for completely unrelated models.

 I now understand why; I just checked and `Abstract.m2m_field.through`
 itself is actually `None`. This makes sense (somewhat) since of course you
 can't have a concrete many to many table for an abstract model. I would
 think one could change `ManyToManyField` to itself be some kind of
 abstract model or a dummy class when attached to an abstract model, but
 you will know more about the inners of Django to know if something like
 that is feasible or justified.
 Replying to [comment:5 Mariusz Felisiak]:
 > `Abstract` is not used in models from the ticket description🤔, it's an
 abstract model that is not inherited from any concrete model. I'm puzzled.

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

Re: [Django] #33405: Documentation for template filter 'escapejs' is extremely unclear

[Django]

#33405: Documentation for template filter 'escapejs' is extremely unclear
-+-
 Reporter:  Jon Ribbens  |Owner:  Jon
 Type:   |  Ribbens
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Ribbens):

 * owner:  nobody => Jon Ribbens
 * status:  new => assigned
 * has_patch:  0 => 1
 * version:  4.0 => dev


Comment:

 Pull Request available at https://github.com/django/django/pull/15430

 Note the PR "fails" the docs check as the spelling checker doesn't
 recognise the valid word "backtick".

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

Re: [Django] #31407: RuntimeWarning when running AsyncHandlerRequestTests.test_unawaited_response.

[Django]

#31407: RuntimeWarning when running
AsyncHandlerRequestTests.test_unawaited_response.
-+-
 Reporter:  Deep Sukhwani|Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  3.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:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"236e6cb5881168a79a194b43c2d8dff7a14c3f03" 236e6cb5]:
 {{{
 #!CommitTicketReference repository=""
 revision="236e6cb5881168a79a194b43c2d8dff7a14c3f03"
 Refs #31407 -- Handled potential exception in test cleanup.

 The test view may not be called when running the tests with
 --parallel=2 or greater. Catch the AttributeError for this case.
 }}}

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

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

Re: [Django] #33348: Change API of assertFormError to take an actual form object

[Django]

#33348: Change API of assertFormError to take an actual form object
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 Type:   |  Mispelon
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"d4c9dab74bc29c240c33879a1167e5fd0971c7bc" d4c9dab]:
 {{{
 #!CommitTicketReference repository=""
 revision="d4c9dab74bc29c240c33879a1167e5fd0971c7bc"
 Refs #33348 -- Fixed SimpleTestCase.assertFormError() error message raised
 for unbound forms.
 }}}

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

Re: [Django] #33348: Change API of assertFormError to take an actual form object

[Django]

#33348: Change API of assertFormError to take an actual form object
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 Type:   |  Mispelon
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"f7e0bffa2e9c8820c008e742f76b71feaf7dd89f" f7e0bffa]:
 {{{
 #!CommitTicketReference repository=""
 revision="f7e0bffa2e9c8820c008e742f76b71feaf7dd89f"
 Refs #33348 -- Made SimpleTestCase.assertFormError() raise ValueError when
 "field" is passed without "form_index".
 }}}

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

Re: [Django] #33510: dumpdata misses models subclassed from other non-abstract models

[Django]

#33510: dumpdata misses models subclassed from other non-abstract models
-+-
 Reporter:  Robin Harms  |Owner:  nobody
  Oredsson   |
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  dumpdata | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Robin Harms Oredsson):

 Hi, sorry about this. You're right - the reason I have this problem is
 that the superclass has a custom manager that causes polymorphic
 behaviour, so the 1-1 relation becomes corrupt. So not a problem with
 Django.

 I thought those custom managers were disabled during exporting though?

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

Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

[Django]

#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
---+---
 Reporter:  Brandon Navra  |Owner:  David Smith
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  dev
 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 Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 A few issues on the PR to resolve, but looking very promising: 39.813s vs
 249.146s on macOS, which is a bit of a speed-up 🙂

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

Re: [Django] #33348: Change API of assertFormError to take an actual form object

[Django]

#33348: Change API of assertFormError to take an actual form object
-+-
 Reporter:  Baptiste Mispelon|Owner:  Baptiste
 Type:   |  Mispelon
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"d84cd91e90cb0871e43f98cba8c53be99053e903" d84cd91e]:
 {{{
 #!CommitTicketReference repository=""
 revision="d84cd91e90cb0871e43f98cba8c53be99053e903"
 Refs #33348 -- Improved messages raised by
 SimpleTestCase.assertFormError()/assertFormsetErrors().

 This makes messages use BaseFormSet/BaseForm.__repr__() instead of
 context, and adds the _assert_form_error() helper.
 }}}

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