Re: [Django] #11541: F() expressions don't allow assignment of Foreign Key values on instances

[Django]

#11541: F() expressions don't allow assignment of Foreign Key values on 
instances
-+-
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.1-beta
  (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 Abhijeet Viswa):

 * cc: Abhijeet Viswa (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.66d355e64feaae0ca75bdfe50c626bd2%40djangoproject.com.

Re: [Django] #11541: F() expressions don't allow assignment of Foreign Key values on instances

[Django]

#11541: F() expressions don't allow assignment of Foreign Key values on 
instances
-+-
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.1-beta
  (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 Abhijeet Viswa):

 I gave a shot at fixing this ticket. However, I got stuck real fast. F
 expressions aren't resolved until the queryset is evaluated. However, the
 test to check if the right-value is an instance of the forward relation's
 class is performed during assignment. The only solution I could think of
 is to defer the test for F expressions until queryset evaluation.

 Maintainers, would this be the best approach?

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

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Here's
 [https://github.com/django/django/compare/master...charettes:ticket-31255
 a branch pushing the idea above further].

 It currently has two failures related to many-to-many field removals
 optimizations in the auto-detector but the additional tests in
 `test_optimizer` demonstrate that changes work as expected. We should
 likely add more tests for the `RemoveField` and `DeleteModel` without
 fields(s) tests but I think this should be a good basis if you want to
 familiarize yourself with the internals of the optimizer.

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

Re: [Django] #31322: Add 'help_text' property to InlineModelAdmin

[Django]

#31322: Add 'help_text' property to InlineModelAdmin
---+--
 Reporter:  rbranche   |Owner:  nobody
 Type:  New feature|   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
---+--
Changes (by rbranche):

 * type:  Uncategorized => New feature


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

[Django] #31322: Add 'help_text' property to InlineModelAdmin

[Django]

#31322: Add 'help_text' property to InlineModelAdmin
-+
   Reporter:  rbranche   |  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  |
-+
 It would be helpful to have a `help_text` property added to the
 InlineModelAdmin and children classes (StackedInline/TabularInline).

 This would be displayed somewhere in the inline edit template (Maybe at
 the very end of the fieldset tag?)

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

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 This is explained in more details in the above links but the crux of the
 issue is that `RemoveField` and `DeleteModel` operations don't hold a
 reference to ''what'' they are removing so
 
[https://github.com/django/django/blob/e65fea9292ffdeb9bb76062f6cb2a5ff514ae969/django/db/migrations/operations/models.py#L268-L271
 they must assume they could be referring to any model].

 In other words, because the `DeleteModel` operation doesn't hold a
 reference to the model state it's removing it cannot differentiate between
 the cases where the optimization can be performed (this ticket's example)
 and when it cannot because there's cycles between models (comment:6).

 You likely can get the optimization working for this ticket by changing
 `DeleteModel.references_model` to return `False` but
 
[https://github.com/django/django/blob/e65fea9292ffdeb9bb76062f6cb2a5ff514ae969/tests/migrations/test_autodetector.py#L2029-L2040
 that I'll break when for the cases where model cycles are deleted in the
 same migration].

 If `DeleteModel` operations were created with the set of fields they have
 at removal time it would be possible for them to properly determine
 whether or not they references each other.

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

Re: [Django] #31321: Unexpected behavior of `update_or_create`, misleading flag `created`. (was: Unexpected behavior of `update_or_create`, misleading flag `created`)

[Django]

#31321: Unexpected behavior of `update_or_create`, misleading flag `created`.
-+-
 Reporter:  plushchaynikolay |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  get_or_create| Triage Stage:
  update_or_create created   |  Unreviewed
  primary_key|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 `get_or_create()` doesn't override existing objects so it's not affected
 by described behavior.

 About `update_or_create()`, it's
 [https://docs.djangoproject.com/en/3.0/ref/models/querysets/#update-or-
 create documented] that this is as a shortcut to boilerplatish a concrete
 code, it's also [https://docs.djangoproject.com/en/3.0/topics/db/queries
 /#copying-model-instances documented] how Django behaves when you update
 `pk` with `None`. If you will take these two into account then this
 behavior is expected. I'm not sure why you created a new model instance
 and used `model_to_dict()` instead of passing dictionary directly to
 `defaults`.

 IMO documenting this edge case or changing `created` to `found` would be
 even more misleading. Changing behavior for `AutoField`'s  would be
 backward incompatible and I don't see a reason 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/074.c0a343434d9ca749d25f26662f02dd76%40djangoproject.com.

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sanskar Jaiswal):

 Forgive me if I come off as a bit unaware, I have just started to work
 with the migrations component. I have been going through the code in the
 meanwhile, and I am confident that the `reduce()` method or
 `MigrationOptimizer`'s `optimize_inner()` method is causing the issue.
 Just to be on the same page, the issue here is that while one
 `RemoveField` gets reduced into `DeleteModel`, while the other does not,
 right?

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

[Django] #31321: Unexpected behavior of `update_or_create`, misleading flag `created`

[Django]

#31321: Unexpected behavior of `update_or_create`, misleading flag `created`
-+-
   Reporter: |  Owner:  nobody
  plushchaynikolay   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  3.0
  layer (models, ORM)|   Keywords:  get_or_create
   Severity:  Normal |  update_or_create created
   Triage Stage: |  primary_key
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Unexpected behavior of `update_or_create` (and `get_or_create`) when
 accidentally overrode primary_key with None-value.
 It was primarily unexpected because of misleading naming of flag
 `created`.

 {{{
 . . .
 self.assertEqual(MyModel.objects.count(), 1)
 # ok

 _, created = MyModel.objects.update_or_create(
 somefield=obj.somefield,
 defaults={**model_to_dict(obj)}
 )

 self.assertFalse(created)
 # ok

 self.assertEqual(MyModel.objects.count(), 1)
 # AssertionError: 2 != 1
 }}}

 `created == False` but `MyModel.objects.count() == 2`, and new object was
 actually created.

 {{{
 >>> model_to_dict(obj)
 {'id': None, 'somefield': 'once told me'}
 }}}

 The field `id` (primary key) is overridden with `None` from
 `defaults={**model_to_dict(obj)}`, and when it does`obj.save()`, then
 `obj.id` is auto incremented with new value. (Same with `get_or_create`)

 We understand that the issue took it's place because of our unknowing of
 how this functions work inside. But actually we shouldn't know it.

 Also have some suggestions, if You don't mind:
 - rename `created` into `found`
 - carefully explain this issue in documentation
 - check if field is autoincrementable and overridden to a None-value
 and ignore overriding
 - check if field is autoincrementable and overridden to a None-value
 and make a warning

 [https://github.com/plushchaynikolay/dj-bug more], desu

-- 
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/059.407b4279c2f346e1b5d94afdc9bbdca7%40djangoproject.com.

Re: [Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
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 Adam (Chainz) Johnson):

 Ah I was not aware the algorithm has been unstable.

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

Re: [Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
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 Simon Charette):

 That approach would also not account for constraint name instabilities
 that shipped over the past years in various Django versions.

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

Re: [Django] #31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations. (was: Prevent BEGIN and COMMIT in RunSQL in atomic migrations)

[Django]

#31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 felixxm):

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


Comment:

 Thanks for this ticket, however `RunSQL()` is ''"useful for more advanced
 features of database backends that Django doesn’t support directly"'',
 moreover you can use `BEGIN` not only to start a transaction, e.g. with
 [https://www.postgresql.org/docs/9.6/sql-do.html DO]. IMO parsing a custom
 SQL provided by users in `RunSQL()` is out of the scope of Django.

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

Re: [Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
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 Adam (Chainz) Johnson):

 An alternative would be to translate `unique_together = [['a']]` into an
 extra constraint in `constraints`` and then it can be treated by
 migrations as `AddConstraint` / `RemoveConstraint` operations. Though that
 might mean more work.

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

Re: [Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
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 Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 We'll likely have to use a specialized `ddl_statement.Statement` subclass
 when deferring constraints and indices and have `_delete_composed_index`
 consider them by looping through `dereferred_sql` before raising that
 exception.

 That would have the benefit of also avoiding creating constraints meant to
 be immediately dropped.

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

Re: [Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
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):

 2.2, 3.0, master

 It isn't squashed in this case because the `unique_together` includes a
 FK.

 https://github.com/adamchainz/django-unique-together-
 bug/blob/master/testproj/testapp/migrations/0001_squashed_0002_add_author.py

 {{{#!python
 # Generated by Django 2.1.15 on 2020-02-28 06:56

 from django.db import migrations, models
 import django.db.models.deletion


 class Migration(migrations.Migration):

 replaces = [("testapp", "0001_initial"), ("testapp",
 "0002_add_author")]

 initial = True

 dependencies = []

 operations = [
 migrations.CreateModel(
 name="Book",
 fields=[
 (
 "id",
 models.AutoField(
 auto_created=True,
 primary_key=True,
 serialize=False,
 verbose_name="ID",
 ),
 ),
 ("title", models.CharField(default="", max_length=100)),
 ],
 options={"unique_together": {("title",)},},
 ),
 migrations.CreateModel(
 name="Author",
 fields=[
 (
 "id",
 models.AutoField(
 auto_created=True,
 primary_key=True,
 serialize=False,
 verbose_name="ID",
 ),
 ),
 ],
 ),
 migrations.AddField(
 model_name="book",
 name="author",
 field=models.ForeignKey(
 null=True,
 on_delete=django.db.models.deletion.DO_NOTHING,
 to="testapp.Author",
 ),
 ),
 migrations.AlterUniqueTogether(
 name="book", unique_together={("title", "author")},
 ),
 ]

 }}}

 It's also possible to hand write such a migration.

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

[Django] #31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations

[Django]

#31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations
-+
   Reporter:  Adam (Chainz) Johnson  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Migrations |Version:  master
   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  |
-+
 Migrations are `atomic` by default, which means they use a transaction on
 backends that support them (PostgreSQL).

 `RunSQL` allows running arbitrary SQL, including `BEGIN` / `COMMIT` which
 break the atomic transaction handling.

 PostgreSQL will warn about `BEGIN` within a transaction (
 https://www.postgresql.org/docs/current/sql-begin.html ) but this warning
 won't be displayed on a standard Django setup. Equally it will warn about
 a `COMMIT` when no transaction is running.

 (SQLite at least raises an error for a `BEGIN` within a transaction).

 Beginners to the migration framework can miss that migrations are 'atomic'
 by default, and use their SQL knowledge to write `BEGIN`/`COMMIT`, not
 realizing they're actually breaking the transactional integrity of their
 migrations.

 It would be good to detect this and refuse to run such `RunSQL`
 operations.

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

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

Re: [Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
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):

 Which version of Django did you use to squash the migrations? A
 `[CreateModel, AlterUniqueTogether]` sequence should get optimized into
 `[CreateModel]`

 
https://github.com/django/django/blob/e65fea9292ffdeb9bb76062f6cb2a5ff514ae969/django/db/migrations/operations/models.py#L145-L154

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

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I'm not sure I understand, the migration file you pointed at clearly has 3
 operations so the ``
 got reduced into the ``.

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

[Django] #31319: urldispatcher does not handle multishlashes

[Django]

#31319: urldispatcher does not handle multishlashes
-+
   Reporter:  Bjoern |  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  |
-+
 while removing nginx in my setup I discovered that the url dispatcher does
 not seem to handle path names correctly

 e.g.
 {{{
 /some/fancy/endpoint
 vs
 /some///fancy/endpoint
 }}}

 nginx did "normalize" that url like a unix system would do
 `cd /usrbin` still brings you to /usr/bin

 not sure if it is intensionally, but I'd assume django would/should handle
 it the same

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

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

Re: [Django] #31293: MultiPartParser support double quotes

[Django]

#31293: MultiPartParser support double quotes
-+-
 Reporter:  007  |Owner:  007
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 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:"e65fea9292ffdeb9bb76062f6cb2a5ff514ae969" e65fea92]:
 {{{
 #!CommitTicketReference repository=""
 revision="e65fea9292ffdeb9bb76062f6cb2a5ff514ae969"
 Fixed #31293 -- Allowed MultiPartParser to handle double-quoted encoded
 headers.
 }}}

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

Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails.

[Django]

#31301: bulk_create with ForeignKey fields with mixed filled/None values fails.
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle sql   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"a21f7b91db273a03abfb47b0580bb39e0043c99a" a21f7b91]:
 {{{
 #!CommitTicketReference repository=""
 revision="a21f7b91db273a03abfb47b0580bb39e0043c99a"
 Fixed #31301 -- Fixed crash of QuerySet.bulk_create() with mixed empty and
 set ForeignKeys to AutoFields on Oracle.
 }}}

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

[Django] #31318: sqlmigrate doesn't allow inspecting migrations that have been squashed

[Django]

#31318: sqlmigrate doesn't allow inspecting migrations that have been squashed
-+
   Reporter:  Adam (Chainz) Johnson  |  Owner:  nobody
   Type:  Cleanup/optimization   | Status:  new
  Component:  Migrations |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 This project for another ticket can be used to reproduce:
 https://github.com/adamchainz/django-unique-together-bug

 When running sqlmigrate to pick up migration 0001 in this project, it
 complains that two migrations have that prefix:

 {{{
 $ python manage.py sqlmigrate testapp 0001
 CommandError: More than one migration matches '0001' in app 'testapp'.
 Please be more specific.
 }}}

 But when trying to be more specific, it's not possible to load it:

 {{{
 $ python manage.py sqlmigrate testapp 0001_initial
 Traceback (most recent call last):
   File "manage.py", line 21, in 
 main()
   File "manage.py", line 17, in main
 execute_from_command_line(sys.argv)
   File "/.../django/django/core/management/__init__.py", line 401, in
 execute_from_command_line
 utility.execute()
   File "/.../django/django/core/management/__init__.py", line 395, in
 execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/.../django/django/core/management/base.py", line 328, in
 run_from_argv
 self.execute(*args, **cmd_options)
   File "/.../django/django/core/management/commands/sqlmigrate.py", line
 30, in execute
 return super().execute(*args, **options)
   File "/.../django/django/core/management/base.py", line 369, in execute
 output = self.handle(*args, **options)
   File "/.../django/django/core/management/commands/sqlmigrate.py", line
 64, in handle
 plan = [(executor.loader.graph.nodes[targets[0]],
 options['backwards'])]
 KeyError: ('testapp', '0001_initial')
 }}}

 It would be nice to:

 A) catch this error and report a nice message as well
 B) allow inspection of individual migrations that have been involved in a
 squash. Normally the workflow is to remove the individual migrations some
 time after committing the squash, but until that is done it could be
 useful to see their sql.

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

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

[Django] #31317: Migration using CreateModel with unique_together followed by AlterUniqueTogether crashes

[Django]

#31317: Migration using CreateModel with unique_together followed by
AlterUniqueTogether crashes
-+
   Reporter:  Adam (Chainz) Johnson  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Migrations |Version:  master
   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  |
-+
 Full project to reproduce: https://github.com/adamchainz/django-unique-
 together-bug

 When squashing migrations I ended up with a migration that added a model
 with `unique_together`, then altered the unique_together later:

 {{{
 migrations.CreateModel(
 name="Book",
 fields=[
 (
 "id",
 models.AutoField(
 auto_created=True,
 primary_key=True,
 serialize=False,
 verbose_name="ID",
 ),
 ),
 ("title", models.CharField(default="", max_length=100)),
 ],
 options={"unique_together": {("title",)},},
 ),
 # ...
 migrations.AlterUniqueTogether(
 name="book", unique_together={("title", "author")},
 ),
 }}}

 This can crash when using `sqlmigrate` or `migrate` (see repo) with:

 {{{
   File "/.../django/django/db/backends/base/schema.py", line 380, in
 alter_unique_together
 self._delete_composed_index(model, fields, {'unique': True},
 self.sql_delete_unique)
   File "/.../django/django/db/backends/base/schema.py", line 414, in
 _delete_composed_index
 ", ".join(columns),
 ValueError: Found wrong number (0) of constraints for testapp_book(title)
 }}}

 This is because `_delete_composed_index` from `AlterUniqueTogehter` tries
 to find the existing constraint name from the database.. But it hasn't
 been created yet, so it could never be found - its SQL is sitting in
 `deferred_sql`.

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

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

Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails. (was: bulk_create with ForeignKey fields with mixed filled/None values fails)

[Django]

#31301: bulk_create with ForeignKey fields with mixed filled/None values fails.
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  1 => 0
 * version:  3.0 => master
 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #31032: Document the minimal supported version of browsers for the admin

[Django]

#31032: Document the minimal supported version of browsers for the admin
-+-
 Reporter:  Claude Paroz |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"8b30360322d4de6687e17ab267a856db4e3c78a6" 8b30360]:
 {{{
 #!CommitTicketReference repository=""
 revision="8b30360322d4de6687e17ab267a856db4e3c78a6"
 Fixed #31032 -- Updated admin browser support FAQ for 2020.

 Following web standards, the modern _evergreen_ browsers are all
 supported. This applies equally to mobile platforms. Assuming current
 trends continue, this should be a sustainable policy.

 Microsoft deprecated all versions of Internet Explorer. IE 11, the last
 version, is described as a "compatibility solution" rather than a web
 browser. Whilst it will receive security updates for the lifetime of
 Windows 10 it's use is actively discouraged.

 The IE 11 downloads page makes it clear: "We recommend you use the new
 Microsoft Edge".
 }}}

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

Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails

[Django]

#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_tests:  0 => 1


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

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

Re: [Django] #31293: MultiPartParser support double quotes

[Django]

#31293: MultiPartParser support double quotes
-+-
 Reporter:  007  |Owner:  007
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 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 Carlton Gibson):

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

Re: [Django] #31314: makemessages doesn't provide feedback when no locale is specified

[Django]

#31314: makemessages doesn't provide feedback when no locale is specified
-+-
 Reporter:  Cristóbal Mackenzie  |Owner:  Cristóbal
 |  Mackenzie
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  3.0
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  i18n | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 In 984531f96eb901f2dca732087171bfe8ced986c3.

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

Re: [Django] #31311: Unneeded escape sequences in character classes

[Django]

#31311: Unneeded escape sequences in character classes
--+
 Reporter:  Kimball Leavitt   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  3.0
 Severity:  Normal|   Resolution:  fixed
 Keywords:  validators, regex | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"7c6b66383da5f9a67142334cd2ed2d769739e8f1" 7c6b663]:
 {{{
 #!CommitTicketReference repository=""
 revision="7c6b66383da5f9a67142334cd2ed2d769739e8f1"
 Fixed #31311 -- Removed unneeded escapes in validator regexes.

 Special characters lose their special meaning inside sets of characters.

 "-" lose its special meaning if it's placed as the first or last
 character.
 }}}

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

[Django] #31316: handler500 called multiple times

[Django]

#31316: handler500 called multiple times
-+
   Reporter:  David Szotten  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  master
   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  |
-+
 i recently came across a situation where a (poorly designed) handler500
 view ended up itself raising exceptions.  i was slightly surprised to
 realise that the error handler ends up getting called once for each
 middleware.  is this expected/desired (or e.g. just a side-effect of the
 current implementation)?

-- 
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/055.a76b8dd3d82e0afdad5782d2c8bbc7fd%40djangoproject.com.

Re: [Django] #31314: makemessages doesn't provide feedback when no locale is specified

[Django]

#31314: makemessages doesn't provide feedback when no locale is specified
-+-
 Reporter:  Cristóbal Mackenzie  |Owner:  Cristóbal
 |  Mackenzie
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  3.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Cristóbal Mackenzie
 * status:  new => assigned


Comment:

 Regression in 0707b824fe77e08ca8b75fcc3738ada694f2a3a6.

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

Re: [Django] #31310: Wrong hint about recursive relationship.

[Django]

#31310: Wrong hint about recursive relationship.
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  Matheus
 Type:   |  Cunha Motta
  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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"308fab924195bdea2fc481e1466c3c3894c03400" 308fab92]:
 {{{
 #!CommitTicketReference repository=""
 revision="308fab924195bdea2fc481e1466c3c3894c03400"
 Refs #31310 -- Added test for check for using intermediate model with
 ambiguous foreign key from model.
 }}}

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

Re: [Django] #31310: Wrong hint about recursive relationship.

[Django]

#31310: Wrong hint about recursive relationship.
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  Matheus
 Type:   |  Cunha Motta
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"e908eb62871f0b0aac63afa6601bf222bc2a1a7d" e908eb6]:
 {{{
 #!CommitTicketReference repository=""
 revision="e908eb62871f0b0aac63afa6601bf222bc2a1a7d"
 Fixed #31310 -- Fixed hints in checks for using intermediate model with
 ambiguous foreign key.

 symmetrical=False is not required since
 87b1ad6e7351464c60e751b483d9dfce3a2d3382.
 }}}

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