Re: [Django] #31623: timesince 'depth' parameter

2020-07-07 Thread Django
#31623: timesince 'depth' parameter
-+
 Reporter:  Toby Such|Owner:  Tim Park
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  timesince| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+
Changes (by felixxm):

 * 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.9508ee80dc11ed9015faf70b2a8a8b1c%40djangoproject.com.


Re: [Django] #24782: Add TestCase.assertFormValid

2020-07-07 Thread Django
#24782: Add TestCase.assertFormValid
---+---
 Reporter:  Marc Tamlyn|Owner:  David Smith
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  forms  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by David Smith):

 * owner:  Joseph Victor Zammit => David Smith


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


Re: [Django] #31769: Improve default name of merge migrations.

2020-07-07 Thread Django
#31769: Improve default name of merge migrations.
-+-
 Reporter:  Jon Dufresne |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   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 felixxm):

 * owner:  nobody => Jon Dufresne
 * needs_better_patch:  0 => 1
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 > I'm also still open to dropping the migration number (_) if that
 makes the filename more readable. I personally like including the number,
 but I'm open to alternatives.

 IMO numbers should be included.

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


Re: [Django] #31739: Document dependency between HttpRequest stream IO methods and body.

2020-07-07 Thread Django
#31739: Document dependency between HttpRequest stream IO methods and body.
-+-
 Reporter:  Adam (Chainz)|Owner:  Tim Park
  Johnson|
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  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 felixxm):

 * owner:  nobody => Tim Park
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13164 PR]

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

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


Re: [Django] #24816: Clarify docs about preventing duplicate signals

2020-07-07 Thread Django
#24816: Clarify docs about preventing duplicate signals
-+-
 Reporter:  Timothy Makobu   |Owner:  Jason
 Type:   |  Held
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | 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):

 * needs_better_patch:  1 => 0
 * version:  1.8 => 3.1
 * stage:  Accepted => Ready for checkin


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

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


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

2020-07-07 Thread 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 Simon Charette):

 I think the proposed patch is ready to be merged. Looks like current
 implementation of `FilteredRelation(condition=~Q)` might do weird things
 under some circumstances but that seems like an artifact of how exclusions
 against multi-valued relationship is currently implemented.

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


Re: [Django] #31769: Improve default name of merge migrations.

2020-07-07 Thread Django
#31769: Improve default name of merge migrations.
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 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 Jon Dufresne):

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


Comment:

 > I'm not sure about this change because you may need to merge many
 migrations. In such case it seems that the timestamp is the best we can do

 In the case or merging lots of files, I agree the timestamp is the best we
 can do.

 To solve this, we can add a threshold for the name length and if exceeded
 fallback to the old timestamp naming. This way, the common case of merging
 two or three migrations has a more useful name, but it doesn't get out of
 hand when more are involved. I'll update the PR with this change and
 include a test.

 Having a threshold for auto-generated migration names has precedent, so we
 can carry that over:

 
https://github.com/django/django/blob/ae8338daf34fd746771e0678081999b656177bae/django/db/migrations/autodetector.py#L1272

 The link uses a length of 100, which I'll use too. But I'm happy to tweak
 this larger or smaller to an agreeable size.

 I'm also still open to dropping the migration number (`_`) if that
 makes the filename more readable. I personally like including the number,
 but I'm open to alternatives.

 > You always use the --name option if you don't like a generated name

 Yes. This is the status quo and my current approach. But it doesn't solve
 my use case of providing more useful name by default. This is especially
 important when working on a diverse team where some members will not
 always remember to use useful names. Catching this before the code gets to
 team review is helpful for all by reducing repetitive feedback and by
 reducing the work a computer can do.

 Beyond that, improving the default now means more projects will likely
 have more useful and reproducible filenames moving forward, regardless of
 their internal standards.

 There have recently been a few other PRs, tickets and discussions on
 improving migration names. IMO, this ticket is along those same goals:

 https://groups.google.com/forum/#!msg/django-
 developers/Bmcd779Wdl4/mlQRVNVgAQAJ
 
https://github.com/django/django/commit/6f3e3e87ab72eb64dcce8e646f8eea07be6c3b7e

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


Re: [Django] #31771: Add warning if model field has trailing comma.

2020-07-07 Thread Django
#31771: Add warning if model field has trailing comma.
-+-
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  master
  checks)|
 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
-+-

Comment (by felixxm):

 It is too specific, we cannot add separate system checks for each kind of
 typos.

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


Re: [Django] #31771: Add warning if model field has trailing comma.

2020-07-07 Thread Django
#31771: Add warning if model field has trailing comma.
-+-
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  master
  checks)|
 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
-+-

Comment (by Jonas Haag):

 From a quick Google search, this seems to be a common mistake made by a
 Django beginners.

 https://stackoverflow.com/questions/7900162/django-error-with-
 orm/7900323#7900323
 https://stackoverflow.com/questions/26090949/unique-together-refers-to-
 the-non-existent-field
 https://stackoverflow.com/questions/4389367/django-unique-together-does-
 not-allow-foreignkey-field-across-applications-when

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


Re: [Django] #31771: Add warning if model field has trailing comma.

2020-07-07 Thread Django
#31771: Add warning if model field has trailing comma.
-+-
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  master
  checks)|
 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
-+-

Comment (by Jonas Haag):

 What do you mean by “supported use case”? Obviously defining tuples on
 model classes generally should not raise a warning, but how about the
 specific case of tuple of size 1 containing a model field instance?

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


Re: [Django] #31770: Enable has_select_for_update_of feature on MySQL 8.0.1+.

2020-07-07 Thread Django
#31770: Enable has_select_for_update_of feature on MySQL 8.0.1+.
-+-
 Reporter:  Simon Charette   |Owner:  nobody
 Type:  New feature  |   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
-+-

Comment (by Simon Charette):

 > `select_for_update` tests fail for me on MySQL 5.6 and 5.7.

 Not sure what I did wrong but I used `django-docker-box` with
 `MYSQL_VERSION=5.5 docker-compose run --rm mysql --noinput
 select_for_update`. I guess there might have been some Docker image
 caching involved.

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


Re: [Django] #31770: Enable has_select_for_update_of feature on MySQL 8.0.1+. (was: Enable has_select_for_update_of feature on MySQL)

2020-07-07 Thread Django
#31770: Enable has_select_for_update_of feature on MySQL 8.0.1+.
-+-
 Reporter:  Simon Charette   |Owner:  nobody
 Type:  New feature  |   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 felixxm):

 * version:  3.0 => master
 * stage:  Unreviewed => Accepted


Comment:

 It looks that it was officially added in
 
[https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html#mysqld-8-0-1-feature
 MySQL 8.0.1]:

 > ''"OF now is a reserved word and cannot be used as an identifier without
 identifier quoting."''

 `select_for_update` tests fail for me on MySQL 5.6 and 5.7.

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


Re: [Django] #31772: Support for field with Roman Numeral

2020-07-07 Thread Django
#31772: Support for field with Roman Numeral
-+-
 Reporter:  Aman Sharma  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 it's quite niche I don't think there's a
 strong reason to create a new model field class. It sounds like a third-
 party package is the best way to proceed.

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


Re: [Django] #31771: Add warning if model field has trailing comma. (was: Add warning if model field has trailing comma)

2020-07-07 Thread Django
#31771: Add warning if model field has trailing comma.
-+-
 Reporter:  Jonas Haag   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  master
  checks)|
 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
 * ui_ux:  1 => 0
 * component:  Database layer (models, ORM) => Core (System checks)


Comment:

 Thanks for this ticket, however we cannot add a system check for tuples
 defined on models. It's a supported use 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/067.085770886ad584d7e3e816f90d5609af%40djangoproject.com.


[Django] #31772: Support for field with Roman Numeral

2020-07-07 Thread Django
#31772: Support for field with Roman Numeral
-+-
   Reporter:  Aman   |  Owner:  nobody
  Sharma |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  3.0
  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  |
-+-
 A Django model field which would have an inbuilt validation to check if
 the value entered is a valid Roman Numeral. It could be something like
 this:
 {{{
 from django.db import models

 class Book(models.Model):

 volume = models.RomanNumeralField()
 }}}

 I wanted to know if this is a good idea or not. If it gets approved, I
 would definitely like to work on 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/055.e04924900849ac445beedb6672c4aeaa%40djangoproject.com.


[Django] #31771: Add warning if model field has trailing comma

2020-07-07 Thread Django
#31771: Add warning if model field has trailing comma
-+-
   Reporter:  Jonas  |  Owner:  nobody
  Haag   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  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:  1  |
-+-
 If someone types (note the trailing comma):

 {{{
 class MyModel(models.Model):
   trailing_comma = models.IntegerField(),
 }}}

 Django silently ignored the field, possibly leaving you wondering for a
 very long time what's going on.

 I suggest to add a warning to the models checker framework.

 If accepted, I'm willing to come up with an initial patch.

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


Re: [Django] #31770: Enable has_select_for_update_of feature on MySQL (was: Enable has_select_for_update_of feature on MySQL 8)

2020-07-07 Thread Django
#31770: Enable has_select_for_update_of feature on MySQL
-+-
 Reporter:  Simon Charette   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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
-+-
Description changed by Simon Charette:

Old description:

> While the `SELECT FOR UPDATE`
> [https://dev.mysql.com/doc/refman/8.0/en/select.html#idm45705194357888
> documentation now mentions the] `OF` option I
> [https://www.oracle.com/search/results?Ntt=%22FOR%20UPDATE%20OF%22=1=1=mysql
> =SI-ALL5 couldn't find a single entry in the release notes] so I'm not
> sure which version of MySQL 8 supposedly added support for it.
>
> All the `tests/select_for_update` tests happen to pass when setting
> `has_select_for_update_of = True` even on MySQL 5.5 so I'm not sure if
> this was always supported and never documented or if the syntax was
> always allowed and they just recently added support for it?
>
> In all cases it seems like the feature should be allowed since all
> supported versions of MySQL allow it.

New description:

 While the `SELECT FOR UPDATE`
 [https://dev.mysql.com/doc/refman/8.0/en/select.html#idm45705194357888
 documentation now mentions the] `OF` option I
 
[https://www.oracle.com/search/results?Ntt=%22FOR%20UPDATE%20OF%22=1=1=mysql
 =SI-ALL5 couldn't find a single entry in the release notes] so I'm not
 sure which version of MySQL supposedly added support for it.

 All the `tests/select_for_update` tests happen to pass when setting
 `has_select_for_update_of = True` even on MySQL 5.5 so I'm not sure if
 this was always supported and never documented or if the syntax was always
 allowed and they just recently added support for it? Only the MySQL 8
 documentation mentions it though.

 In all cases it seems like the feature should be allowed since all
 supported versions of MySQL allow 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/067.62cc9a4e3d7c9ace57fd77783b63d1ca%40djangoproject.com.


[Django] #31770: Enable has_select_for_update_of feature on MySQL 8

2020-07-07 Thread Django
#31770: Enable has_select_for_update_of feature on MySQL 8
-+-
   Reporter:  Simon  |  Owner:  nobody
  Charette   |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  3.0
  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  |
-+-
 While the `SELECT FOR UPDATE`
 [https://dev.mysql.com/doc/refman/8.0/en/select.html#idm45705194357888
 documentation now mentions the] `OF` option I
 
[https://www.oracle.com/search/results?Ntt=%22FOR%20UPDATE%20OF%22=1=1=mysql
 =SI-ALL5 couldn't find a single entry in the release notes] so I'm not
 sure which version of MySQL 8 supposedly added support for it.

 All the `tests/select_for_update` tests happen to pass when setting
 `has_select_for_update_of = True` even on MySQL 5.5 so I'm not sure if
 this was always supported and never documented or if the syntax was always
 allowed and they just recently added support for it?

 In all cases it seems like the feature should be allowed since all
 supported versions of MySQL allow 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/052.fcc8cf528e05a884cb8e63cd2d39e5a1%40djangoproject.com.


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2020-07-07 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
---+
 Reporter:  Tom Forbes |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+

Comment (by Tom Forbes):

 Oops, I missed that comment. I left a reply. I'm happy to go with the
 crowd and implement that suggestion if that's the general consensus and
 that enables this to be merged, but I can't help but feel it's not the
 right path.

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


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2020-07-07 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
---+
 Reporter:  Tom Forbes |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+

Comment (by Claude Paroz):

 What about Simon's suggestion on the pull request?

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


Re: [Django] #31766: Avoid unneccessary computation in GDALRaster.transform().

2020-07-07 Thread Django
#31766: Avoid unneccessary computation in GDALRaster.transform().
--+
 Reporter:  Riccardo  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  GDALRaster; GIS   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by felixxm):

 * cc: Daniel Wiesmann (added)


Comment:

 > Does it need to implement `def clone` for `GDALRaster`?

 Yes.

 > If so, should we use `copy_ds` from `django.contrib.gis.gdal.prototypes`
 to copy the `ds_input` and create a new `GDALRaster` object?

 Probably, I'm not an expert.

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


Re: [Django] #31767: QuerySet.none() on combined queries returns all results.

2020-07-07 Thread Django
#31767: QuerySet.none() on combined queries returns all results.
-+-
 Reporter:  Tom Carrick  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 GitHub ):

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


Comment:

 In [changeset:"ae8338daf34fd746771e0678081999b656177bae" ae8338da]:
 {{{
 #!CommitTicketReference repository=""
 revision="ae8338daf34fd746771e0678081999b656177bae"
 Fixed #31767 -- Fixed QuerySet.none() on combined queryset.
 }}}

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


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2020-07-07 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
---+
 Reporter:  Tom Forbes |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+

Comment (by Tom Forbes):

 This is the output from the `sqlite3` CLI tool, running the MacOS sqlite3:

 {{{
 BUG_COMPATIBLE_20160819
 COMPILER=clang-11.0.3
 DEFAULT_CACHE_SIZE=2000
 DEFAULT_CKPTFULLFSYNC
 DEFAULT_JOURNAL_SIZE_LIMIT=32768
 DEFAULT_PAGE_SIZE=4096
 DEFAULT_SYNCHRONOUS=2
 DEFAULT_WAL_SYNCHRONOUS=1
 ENABLE_API_ARMOR
 ENABLE_COLUMN_METADATA
 ENABLE_DBSTAT_VTAB
 ENABLE_FTS3
 ENABLE_FTS3_PARENTHESIS
 ENABLE_FTS3_TOKENIZER
 ENABLE_FTS4
 ENABLE_FTS5
 ENABLE_JSON1
 ENABLE_LOCKING_STYLE=1
 ENABLE_PREUPDATE_HOOK
 ENABLE_RTREE
 ENABLE_SESSION
 ENABLE_SNAPSHOT
 ENABLE_SQLLOG
 ENABLE_UNKNOWN_SQL_FUNCTION
 ENABLE_UPDATE_DELETE_LIMIT
 HAVE_ISNAN
 MAX_LENGTH=2147483645
 MAX_MMAP_SIZE=1073741824
 MAX_VARIABLE_NUMBER=50
 OMIT_AUTORESET
 OMIT_LOAD_EXTENSION
 STMTJRNL_SPILL=131072
 THREADSAFE=2
 USE_URI
 }}}

 I can't see anything there that would be suitable to to safely detect
 MacOS bundled SQLite. We could maybe branch off "COMPILER" and maybe
 "BUG_COMPATIBLE_20160819" but it seems equally as dirty.

 So, just to re-iterate the point above: This code path should only be
 called during migrations. While feature detection is definitely slower, in
 this case I feel that it's warranted - looking through the git history for
 this specific flag the version range has been changed previously, and it's
 not in the hot path of any requests and shouldn't slow down startup.

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


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2020-07-07 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
---+
 Reporter:  Tom Forbes |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+

Comment (by Carlton Gibson):

 > .. but there is no other way I can find to detect a "MacOS" sqlite vs
 another SQLite.

 @Tom: can you try `PRAGMA compile_options;` against the two versions? (If
 we can see why the difference is then...) 樂

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


Re: [Django] #12203: ManyToManyField with through model can't be used in admin

2020-07-07 Thread Django
#12203: ManyToManyField with through model can't be used in admin
-+-
 Reporter:  David Gouldin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  M2M, admin,  | Triage Stage:  Accepted
  through, through_fields|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Dennis):

 Replying to [comment:22 Dmitry Mugtasimov]:

 The trick of setting `JobTitleExperienceThrough._meta.auto_created = True`
 in `formfield_for_manytomany` does indeed enable the
 `ModelMultipleChoiceField` on the admin page without causing migration
 issues (as far as I can see).

 However, there is a dangerous side-effect of using this, in case you have
 other models with a "cascading" relation directly to your explicit
 through-model, e.g. `models.ForeignKey(to=JobTitleExperienceThrough,
 on_delete=models.CASCADE)`:

 If the initial queryset for the m2m field `JobTitle.experiences` is
 filtered (e.g. as in the docs
 
[https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.formfield_for_manytomany]),
 and, for whatever reason, the filter excludes some `Experience` objects
 that have previously been assigned, then the corresponding records from
 `JobTitleExperienceThrough` will be silently deleted, including any
 records for other models pointing to them.

 This means there is a serious potential for "silent" data loss.

 This is because the many-to-many relation will now be updated using
 `ManyRelatedManager.set()` (via `ModelAdmin.save_related()` ->
 `form.save_m2m()` -> `BaseModelForm._save_m2m()` ->
 `ManyToManyField.save_form_data()`).

 Silent deletion could be prevented by setting `on_delete=models.PROTECT`
 on any relation to the explicit through-model, but then you would first
 have to be aware of the necessity.

 When using a "real" auto-created `through` table (i.e. an implicit one)
 the issue does not arise, because there is no way to set a `ForeignKey` to
 the implicit `through`, as far as I know.

 When using an inline for `JobTitleExperienceThrough`, this issue does not
 occur.

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

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


Re: [Django] #14645: Exclude query with multiple conditions for the same multi-value relation not correct

2020-07-07 Thread Django
#14645: Exclude query with multiple conditions for the same multi-value relation
not correct
-+-
 Reporter:  Ben Buchwald |Owner:  nobody
  |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  exclude manytomany   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * 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/094.732aac7978940cb3a4184618b3a2e721%40djangoproject.com.


Re: [Django] #31747: Avoid potential admin model enumeration

2020-07-07 Thread Django
#31747: Avoid potential admin model enumeration
---+
 Reporter:  Daniel Maxson  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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 Carlton Gibson):

 * needs_better_patch:  0 => 1
 * version:  3.0 => 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/065.c47e79173041518b5c07e3f56df6e158%40djangoproject.com.


Re: [Django] #31713: Adding srs parameter to GDALRaster.transform().

2020-07-07 Thread Django
#31713: Adding srs parameter to GDALRaster.transform().
-+-
 Reporter:  Riccardo |Owner:  Riccardo
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  GDALRaster; GIS; | Triage Stage:  Ready for
  SpatialReference   |  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:"cb0da637a69b79ab371be9ee202335190a3a506e" cb0da63]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb0da637a69b79ab371be9ee202335190a3a506e"
 Fixed #31713 -- Added SpatialReference support to GDALRaster.transform().
 }}}

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


Re: [Django] #31573: Support update().order_by() on MySQL.

2020-07-07 Thread Django
#31573: Support update().order_by() on MySQL.
-+-
 Reporter:  Gerben Morsink   |Owner:  David
 |  Chorpash
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  update mysql order   | Triage Stage:  Accepted
  order_by   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * 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/064.db43fe3e97e000bc2db2609a03fce201%40djangoproject.com.


Re: [Django] #31768: `django.http.request` `validate_domains` - should be optional "Invalid HTTP_HOST header"

2020-07-07 Thread Django
#31768: `django.http.request` `validate_domains` - should be optional "Invalid
HTTP_HOST header"
-+-
 Reporter:  Mateusz Kurowski |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  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:

 [https://en.wikipedia.org/wiki/Hostname#Syntax Underscores are not
 permitted in hostnames].  Remove the `_`:

 {{{
 >>> from django.http.request import split_domain_port
 >>> split_domain_port('my_service:8000')
 ('', '')
 >>> split_domain_port('myservice.com:8000')
 ('myservice.com', '8000')
 >>> split_domain_port('my-service.com:8000')
 ('my-service.com', '8000')
 }}}

 Please see TicketClosingReasons/UseSupportChannels.

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


Re: [Django] #31764: Add a way to allow subdomain wildcards in the set of allowed hosts for redirects after login/logout

2020-07-07 Thread Django
#31764: Add a way to allow subdomain wildcards in the set of allowed hosts for
redirects after login/logout
+--
 Reporter:  Jordan Hayashi  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  contrib.auth|  Version:  master
 Severity:  Normal  |   Resolution:  needsinfo
 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 Carlton Gibson):

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


Comment:

 Hi Jordan. Thanks for the idea.

 I'm not sure what to say:

 How pressing is the need? Do we want to add the additional complexity here
 to save updating a presumably small list of subdomains that we'd actually
 redirect to? For those cases that truly need a dynamic wildcard value,
 should we not prefer recommending a subclass in that case? (And so on.)

 There's two steps:

 * Adding `allow_wildcards` to
 `django.utils.http.url_has_allowed_host_and_scheme()`
 * And using that in Login/Logout view.

 The handy
 
[https://github.com/django/django/compare/master...jhhayashi:jhh/allow_wildcard_host_redirects
 Compare view].

 Can I ask you to propose this on the DevelopersMailingList for a wider
 audience? Please explain your use-case and hint at answers to the
 questions here.
 If there's consensus there then we can proceed.
 Thanks.

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


Re: [Django] #31713: Adding srs parameter to GDALRaster.transform().

2020-07-07 Thread Django
#31713: Adding srs parameter to GDALRaster.transform().
-+-
 Reporter:  Riccardo |Owner:  Riccardo
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  GDALRaster; GIS; | Triage Stage:  Ready for
  SpatialReference   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  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/065.11d8aa03be5d50eea18c5a9ed88bbefd%40djangoproject.com.


Re: [Django] #26367: Assess if FieldFile can work with stdlib File instead of requiring Django's File

2020-07-07 Thread Django
#26367: Assess if FieldFile can work with stdlib File instead of requiring 
Django's
File
-+-
 Reporter:  Cristiano Coelho |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  closed
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  file storage | 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:   => 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/070.6948c8894edfa33f803dae78cae07a8a%40djangoproject.com.


Re: [Django] #31759: Why do instance hints in ForwardManyToOneDescriptor use the related object?

2020-07-07 Thread Django
#31759: Why do instance hints in ForwardManyToOneDescriptor use the related 
object?
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.0
  (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 Carlton Gibson):

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


Comment:

 Hiya. This kind of enquiry isn't really appropriate for the issue tracker.
 Please see TicketClosingReasons/UseSupportChannels.

 The is precisely the **other object** in the relation, so `value` for
 `instance` and `instance` for `value`, allowing the router to adjust the
 write DB depending on the related model.
 Making your change, there's a failure in `tests/multiple_database`. I'd
 guess digging through that would reveal more.

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