Re: [Django] #28535: Message on conflicting migrations is misleading for rebase workflows

[Django]

#28535: Message on conflicting migrations is misleading for rebase workflows
-+-
 Reporter:  karyon   |Owner:  Masashi SHIBATA
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  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 Masashi SHIBATA):

 * 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.608ca1aaec910f829e11c0b0cfeb1914%40djangoproject.com.

Re: [Django] #31106: Adding foreign keys and instances in the same migration crashes on PostgreSQL 10+.

[Django]

#31106: Adding foreign keys and instances in the same migration crashes on
PostgreSQL 10+.
-+-
 Reporter:  Janne Rönkkö |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgresql   | Triage Stage:  Accepted
  migrations |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"0f8041abd5bf0977d28b676445d35a81c6b7b5de" 0f8041a]:
 {{{
 #!CommitTicketReference repository=""
 revision="0f8041abd5bf0977d28b676445d35a81c6b7b5de"
 [3.0.x] Fixed #31106 -- Fixed migrations crash on PostgreSQL 10+ when
 adding FK constraints inline and changing data.

 This allows adding foreign key constraints inline and changing data in
 the same migration on PostgreSQL 10+.

 Regression in 738faf9da2a5cd03148a36375db80746c99c9623.

 Thanks Janne Rönkkö for the report and Simon Charette for the
 implementation idea and review.
 Backport of 22ce5d0031bd795ade081394043833e82046016c from master
 }}}

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

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

Re: [Django] #31106: Adding foreign keys and instances in the same migration crashes on PostgreSQL 10+.

[Django]

#31106: Adding foreign keys and instances in the same migration crashes on
PostgreSQL 10+.
-+-
 Reporter:  Janne Rönkkö |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgresql   | Triage Stage:  Accepted
  migrations |
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:"22ce5d0031bd795ade081394043833e82046016c" 22ce5d00]:
 {{{
 #!CommitTicketReference repository=""
 revision="22ce5d0031bd795ade081394043833e82046016c"
 Fixed #31106 -- Fixed migrations crash on PostgreSQL 10+ when adding FK
 constraints inline and changing data.

 This allows adding foreign key constraints inline and changing data in
 the same migration on PostgreSQL 10+.

 Regression in 738faf9da2a5cd03148a36375db80746c99c9623.

 Thanks Janne Rönkkö for the report and Simon Charette for the
 implementation idea and review.
 }}}

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

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

Re: [Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests.

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests.
---+
 Reporter:  Matthijs Kooijman  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 Matthijs Kooijman):

 Oh, never mind the last part of my previous comment. Maybe I failed to
 stress that this only fails with MySQL and Postgres, while SQLite is
 unaffected (because it uses no NAME for the in-memory database used by
 default). So running with mysql and `--parallel 1` does indeed fail:

 {{{
 ./runtests.py multiple_database.tests backends.base backends.tests
 --parallel 1
 }}}

 But removing `-parallel makes things work again, so there is likely some
 ordering difference there.

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

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

Re: [Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests.

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests.
---+
 Reporter:  Matthijs Kooijman  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 Matthijs Kooijman):

 `./runtests.py multiple_database.tests backends.base backends.tests`
   works without any issues.

 Oh, interesting. Parallelization might indeed be related (I can imagine
 that when parallelization causes the two problematic tests to be ran in
 different threads and/or different order, this might not break).

 However, something else seems to be going on (as well maybe). The command
 you gave indeed works, but when I add `--parallel 1` (which would ensure
 the problematic tests are ran in the problematic order), it still works:

 {{{
 ./runtests.py multiple_database.tests backends.base backends.tests
 --parallel 1
 }}}

 Maybe there is some tests that, when ran in between, prevents this problem
 from occuring? OTOH, when I run the *entire* test suite, with
 parallelization, IIRC the problem *also* occurs.

 Regardless, I believe my analysis and proposed solution still hold. I just
 tried the fix and it seems to work, so pullrequest coming up.

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

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

Re: [Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests. (was: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests)

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests.
---+
 Reporter:  Matthijs Kooijman  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 felixxm):

 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => Testing framework


Comment:

 > Is the configuration for the Jenkins tests published somewhere? Maybe
 that would offer a clue about this difference.

 No, but it doesn't contain anything unusual. Jenkins runs the entire test
 suite without a `parallel` flag, that's why it works. For example
 {{{
 > ./runtests.py multiple_database.tests backends.base backends.tests
 }}}
 works without any issues.

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

[Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests
-+
   Reporter:  Matthijs Kooijman  |  Owner:  nobody
   Type:  Bug| 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  |
-+
 While working on testcases for #26552 and #31051 I ran into some problems
 with
 testing against a local MySQL and Postgres server. I initially thought my
 testcases broke things, but it turns out I can see the same broken
 behaviour on
 a clean master. Hence this ticket.

 In short, what happens is that
 `backends.base.test_creation.TestDbCreationTests` runs `create_test_db` to
 verify migration is (not) run depending on the `MIGRATE` settings.
 However,
 this has two problems:

  - This runs `create_test_db` on an already initialized database, leading
 to
double initialization (in particular, it adds a *second* `test_` prefix
 to the
database name, which produces an unexpected database name.
  - `create_test_db` has side effects that are not properly cleaned up.
 Some of them
are reverted by restoring `settings_dict` (see below), but not all of
 them
(more on this below).

 === Possible solution

 A solution to both issues could be to use a separate database, that is not
 normally used by other tests and thus not initialized by the test runner.
 This
 test can then freely call `create_test_db` to initialize it (possible even
 actually creating the database), and then call `destroy_test_db` to clean
 up
 everthing again.

 I have alredy been working on adding an extra database like this, since
 this
 was also a possible solution to problems I had with
 https://github.com/django/django/pull/12166

 === To reproduce

 On my system, the partial reverting leads to an exception in a later test
 due
 to a fairly obscure interaction between various parts (details below).

 To reproduce this exception, I've used the commands below. Note that the
 `multiple_databases.tests` are not related to this bug directly, but used
 to
 work around #31055.

 {{{
 $ ./runtests.py --settings test_postgresql multiple_database.tests
 backends.base.test_creation.TestDbCreationTests backends.tests.ThreadTests
 --parallel 1
   File "/home/matthijs/docs/src/upstream/django/venv/lib/python3.7/site-
 packages/psycopg2/__init__.py", line 126, in connect
 conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
 psycopg2.OperationalError: FATAL:  database "test_test_django_main" does
 not exist

 $ ./runtests.py --settings test_mysql multiple_database.tests
 backends.base.test_creation.TestDbCreationTests backends.tests.ThreadTests
 --parallel 1

   File "/home/matthijs/docs/src/upstream/django/venv/lib/python3.7/site-
 packages/MySQLdb/connections.py", line 179, in __init__
 super(Connection, self).__init__(*args, **kwargs2)
 MySQLdb._exceptions.OperationalError: (1044, "Access denied for user
 'test_django'@'localhost' to database 'test_test_django_main'")
 }}}

 Interestingly enough, this happens for me locally, but not with the
 automatic
 testing on Jenkins. I originally suspected that this was because my MySQL
 permissions were set up strictly (only allowing access to
 `test_django_*`), but
 for postgresql, the error was not about permissions. Also, when I relaxed
 the
 MySQL permissions, the error only changed to `(1049, "Unknown database
 'test_test_django_main'")`.

 Is the configuration for the Jenkins tests published somewhere? Maybe that
 would offer a clue about this difference.

 === Analysis

 I dug a little deeper to figure out why this exception occurs exactly.
 This is what happens:

 First, `create_test_db` prepends `test_` to the database name, and
 configures this in two places:

 {{{
 settings.DATABASES[self.connection.alias]["NAME"] = test_database_name
 self.connection.settings_dict["NAME"] = test_database_name
 }}}

 See
 
https://github.com/django/django/blob/cebd41e41603c3ca77c5b29d6cd20c1bff43827f/django/db/backends/base/creation.py#L33

 Since the test runner has previously called `create_test_db`, the database
 name now has a `test_test_` prefix.

 At this time, self.connection.settings_dict is the same dict as
 `django.db.connections.databases`, so that one is also changed.

 At the end of the test, `connection.settings_dict` is restored to a copy
 made before the test. This replaces the entire dict instead of modifying
 the
 dict, so `django.db.connections.databases` is *not* restored and still has
 the `test_test_` prefix.

 {{{
 

Re: [Django] #30819: Locales that prioritize 2-digit years shows invalid year in admin date picker.

[Django]

#30819: Locales that prioritize 2-digit years shows invalid year in admin date
picker.
-+-
 Reporter:  Aldian Fazrihady |Owner:  Farhaan
 |  Bukhsh
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  datepicker   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Farhaan Bukhsh):

 * owner:  Aldian Fazrihady => Farhaan Bukhsh
 * needs_better_patch:  1 => 0
 * needs_tests:  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.29837247785e93c7291189b4a395d243%40djangoproject.com.

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  orm, alias   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1e45b06cfd87c4866a201202200ae888a8b8e259" 1e45b06]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e45b06cfd87c4866a201202200ae888a8b8e259"
 [3.0.x] Refs #31115 -- Added test for nested subquery that references
 related fields.

 Thanks Dmitriy Gunchenko for the report and Simon Charette for the
 analysis and tests.

 Regression in 5a4d7285bd10bd40d9f7e574a7c421eb21094858.

 Fixed in 5a4d7285bd10bd40d9f7e574a7c421eb21094858.
 Backport of 45bcc6feac68165eb3642d3c308c74b4828e679e from master
 }}}

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

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

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  orm, alias   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"45bcc6feac68165eb3642d3c308c74b4828e679e" 45bcc6fe]:
 {{{
 #!CommitTicketReference repository=""
 revision="45bcc6feac68165eb3642d3c308c74b4828e679e"
 Refs #31115 -- Added test for nested subquery that references related
 fields.

 Thanks Dmitriy Gunchenko for the report and Simon Charette for the
 analysis and tests.

 Regression in 5a4d7285bd10bd40d9f7e574a7c421eb21094858.

 Fixed in 5a4d7285bd10bd40d9f7e574a7c421eb21094858.
 }}}

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

Re: [Django] #31114: request.build_absolute_uri does not support reverse_lazy

[Django]

#31114: request.build_absolute_uri does not support reverse_lazy
+
 Reporter:  Dmitrij Strelnikov  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (URLs) |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12246

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

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  orm, alias   | 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):

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


Comment:

 Fixed in 5a4d7285bd10bd40d9f7e574a7c421eb21094858.

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

Re: [Django] #30998: Make it easier to use the model instance in ChoiceWidget.create_option()

[Django]

#30998: Make it easier to use the model instance in ChoiceWidget.create_option()
--+
 Reporter:  Jon Dufresne  |Owner:  Jon Dufresne
 Type:  New feature   |   Status:  closed
Component:  Forms |  Version:  master
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"67ea35df52f2e29bafca8881e4f356934061644e" 67ea35df]:
 {{{
 #!CommitTicketReference repository=""
 revision="67ea35df52f2e29bafca8881e4f356934061644e"
 Fixed #30998 -- Added ModelChoiceIteratorValue to pass the model instance
 to ChoiceWidget.create_option().
 }}}

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

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

Re: [Django] #30998: Make it easier to use the model instance in ChoiceWidget.create_option()

[Django]

#30998: Make it easier to use the model instance in ChoiceWidget.create_option()
--+
 Reporter:  Jon Dufresne  |Owner:  Jon Dufresne
 Type:  New feature   |   Status:  assigned
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"5da85ea73724d75e609c5ee4316e7e5be8f17810" 5da85ea7]:
 {{{
 #!CommitTicketReference repository=""
 revision="5da85ea73724d75e609c5ee4316e7e5be8f17810"
 Refs #30998 -- Doc'd ModelChoiceField/ModelMultipleChoiceField.iterator
 attributes and ModelChoiceIterator.
 }}}

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

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  orm, alias   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Replying to [comment:6 Dmitriy Gunchenko]:
 > yes, just tested against it and it works!

 Thanks +1, I will prepare PR with a Simon's test to avoid regressions in
 the future.

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

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  orm, alias   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Dmitriy Gunchenko):

 Replying to [comment:5 felixxm]:
 > Dmitriy, Can you just confirm that your issue is fixed against the
 current master?
 yes, just tested against it and it works!

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

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  orm, alias   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Dmitriy, Can you just confirm that your issue is fixed against the current
 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/064.fb674bf448da19463496e8ab4da745b7%40djangoproject.com.

Re: [Django] #31115: ORM generates wrong alias for subquery

[Django]

#31115: ORM generates wrong alias for subquery
-+-
 Reporter:  Dmitriy Gunchenko|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  orm, alias   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Dmitriy Gunchenko):

 Replying to [comment:3 Simon Charette]:
 > Looks like the `external_aliases` tweaks of
 5a4d7285bd10bd40d9f7e574a7c421eb21094858 which will be part of Django
 3.0.2 happened to address this issue or at least the following regression
 test which crashes on PostgreSQL without the test.
 >
 > {{{#!diff
 > diff --git a/tests/aggregation/tests.py b/tests/aggregation/tests.py
 > index 5ba2e180e0..4febf96d94 100644
 > --- a/tests/aggregation/tests.py
 > +++ b/tests/aggregation/tests.py
 > @@ -1190,3 +1190,15 @@ class AggregateTestCase(TestCase):
 >  contact_publisher__isnull=False,
 >  ).annotate(count=Count('authors'))
 >  self.assertSequenceEqual(books_qs, [book])
 > +
 > +def test_nested_subquery_join_outerref(self):
 > +list(Author.objects.annotate(
 > +friends_book=Subquery(Book.objects.filter(
 > +authors__in=Subquery(
 > +Author.objects.filter(
 > +id=OuterRef('authors__friends__id'),
 > +).values('pk')
 > +),
 > +authors__friends__id=OuterRef('id'),
 > +).values('pk'))
 > +))
 > }}}
 >
 > Dmitriy, could you form your issue is effectively addressed by the
 aforementioned patch?
 >
 > I guess we should polish the test and add it to the suite at an
 appropriate location given it has nothing to do with aggregation.
 Thoughts?

 Hi, sorry but just to be sure - you want me to change bug description and
 use your patch as example instead of code I posted?

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

Re: [Django] #31116: Running test in parallel seems broken. (was: running test in parallel seems broken)

[Django]

#31116: Running test in parallel seems broken.
---+--
 Reporter:  Thierry Bastian|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  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 felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * type:  Uncategorized => Bug
 * component:  Uncategorized => Testing framework


Comment:

 Please don't use Trac as a support channel.

 Closing per 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/067.c7be5bf3480330ba1108b3331e2b3524%40djangoproject.com.

Re: [Django] #31109: Multiple annotation with Subquery generates wrong SQL.

[Django]

#31109: Multiple annotation with Subquery generates wrong SQL.
-+-
 Reporter:  Thierry Bastian  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7b065c41e406fb22d39d1f7b4cfed96bf06dc591" 7b065c41]:
 {{{
 #!CommitTicketReference repository=""
 revision="7b065c41e406fb22d39d1f7b4cfed96bf06dc591"
 [3.0.x] Fixed #31109 -- Disabled grouping by aliases on QuerySet.exists().

 Clearing the SELECT clause in Query.has_results was orphaning GROUP BY
 references to it.

 Thanks Thierry Bastian for the report and Baptiste Mispelon for the
 bisect.

 Regression in fb3f034f1c63160c0ff13c609acd01c18be12f80.

 Backport of 720de4d0441fcfdb543051389c70efbe66ed962a from master
 }}}

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

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

Re: [Django] #31109: Multiple annotation with Subquery generates wrong SQL.

[Django]

#31109: Multiple annotation with Subquery generates wrong SQL.
-+-
 Reporter:  Thierry Bastian  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"720de4d0441fcfdb543051389c70efbe66ed962a" 720de4d]:
 {{{
 #!CommitTicketReference repository=""
 revision="720de4d0441fcfdb543051389c70efbe66ed962a"
 Fixed #31109 -- Disabled grouping by aliases on QuerySet.exists().

 Clearing the SELECT clause in Query.has_results was orphaning GROUP BY
 references to it.

 Thanks Thierry Bastian for the report and Baptiste Mispelon for the
 bisect.

 Regression in fb3f034f1c63160c0ff13c609acd01c18be12f80.
 }}}

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

Re: [Django] #31116: running test in parallel seems broken

[Django]

#31116: running test in parallel seems broken
-+--
 Reporter:  Thierry Bastian  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Thierry Bastian):

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


Comment:

 any guidance would be appreciated...

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

Re: [Django] #31116: running test in parallel seems broken

[Django]

#31116: running test in parallel seems broken
-+--
 Reporter:  Thierry Bastian  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  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 Thierry Bastian):

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


Comment:

 I cannot reproduce it with a clean environment...

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

[Django] #31116: running test in parallel seems broken

[Django]

#31116: running test in parallel seems broken
---+
   Reporter:  Thierry Bastian  |  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|
---+
 Running my existing unit tests works fine. As soon as I try to run them
 with --parallel=4
 I'm getting tons of errors


 {{{
 Process SpawnPoolWorker-17:
 Traceback (most recent call last):
   File
 "/usr/local/filewave/python/lib/python3.8/multiprocessing/process.py",
 line 313, in _bootstrap
 self.run()
   File
 "/usr/local/filewave/python/lib/python3.8/multiprocessing/process.py",
 line 108, in run
 self._target(*self._args, **self._kwargs)
   File "/usr/local/filewave/python/lib/python3.8/multiprocessing/pool.py",
 line 114, in worker
 task = get()
   File
 "/usr/local/filewave/python/lib/python3.8/multiprocessing/queues.py", line
 358, in get
 return _ForkingPickler.loads(res)
   File
 "/Users/thierry/github/FileWave/Django/fwauth/tests/tests_server.py", line
 3, in 
 from django.contrib.auth.models import Permission
   File "/usr/local/filewave/python/lib/python3.8/site-
 packages/django/contrib/auth/models.py", line 2, in 
 from django.contrib.auth.base_user import AbstractBaseUser,
 BaseUserManager
   File "/usr/local/filewave/python/lib/python3.8/site-
 packages/django/contrib/auth/base_user.py", line 47, in 
 class AbstractBaseUser(models.Model):
   File "/usr/local/filewave/python/lib/python3.8/site-
 packages/django/db/models/base.py", line 107, in __new__
 app_config = apps.get_containing_app_config(module)
   File "/usr/local/filewave/python/lib/python3.8/site-
 packages/django/apps/registry.py", line 252, in get_containing_app_config
 self.check_apps_ready()
   File "/usr/local/filewave/python/lib/python3.8/site-
 packages/django/apps/registry.py", line 135, in check_apps_ready
 raise AppRegistryNotReady("Apps aren't loaded yet.")
 django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
 }}}


 Am I missing something?

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