Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

2019-11-12 Thread Django
#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | 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):

 * cc: Markus Holtermann (added)


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

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


Re: [Django] #30982: django.db.backends.postgresql is not one of available backends. (was: error al hacer migraciones)

2019-11-12 Thread Django
#30982: django.db.backends.postgresql is not one of available backends.
-+-
 Reporter:  Danny-Tech   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => Database layer (models, ORM)


Old description:

> ayuda por favor al hacer las miigraciones para conectarme con postgres me
> sale este error:
>
> Traceback (most recent call last):
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\utils.py", line 110, in load_backend
> return import_module('%s.base' % backend_name)
>   File
> "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\importlib\__init__.py",
> line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1006, in _gcd_import
>   File "", line 983, in _find_and_load
>   File "", line 953, in
> _find_and_load_unlocked
>   File "", line 219, in
> _call_with_frames_removed
>   File "", line 1006, in _gcd_import
>   File "", line 983, in _find_and_load
>   File "", line 965, in
> _find_and_load_unlocked
> ModuleNotFoundError: No module named 'django.db.backends.postgresql'
>
> The above exception was the direct cause of the following exception:
>
> 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 "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\core\management\__init__.py", line 381, in
> execute_from_command_line
> utility.execute()
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\core\management\__init__.py", line 357, in execute
> django.setup()
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\__init__.py", line 24, in setup
> apps.populate(settings.INSTALLED_APPS)
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\apps\registry.py", line 114, in populate
> app_config.import_models()
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\apps\config.py", line 211, in import_models
> self.models_module = import_module(models_module_name)
>   File
> "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\importlib\__init__.py",
> line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1006, in _gcd_import
>   File "", line 983, in _find_and_load
>   File "", line 967, in
> _find_and_load_unlocked
>   File "", line 677, in _load_unlocked
>   File "", line 728, in exec_module
>   File "", line 219, in
> _call_with_frames_removed
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\contrib\auth\models.py", line 2, in 
> from django.contrib.auth.base_user import AbstractBaseUser,
> BaseUserManager
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\contrib\auth\base_user.py", line 47, in 
> class AbstractBaseUser(models.Model):
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\models\base.py", line 117, in __new__
> new_class.add_to_class('_meta', Options(meta, app_label))
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\models\base.py", line 321, in add_to_class
> value.contribute_to_class(cls, name)
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\models\options.py", line 204, in contribute_to_class
> self.db_table = truncate_name(self.db_table,
> connection.ops.max_name_length())
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\__init__.py", line 28, in __getattr__
> return getattr(connections[DEFAULT_DB_ALIAS], item)
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\utils.py", line 201, in __getitem__
> backend = load_backend(db['ENGINE'])
>   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
> packages\django\db\utils.py", line 125, in 

Re: [Django] #23435: GenericForeignKey should be indexed

2019-11-12 Thread Django
#23435: GenericForeignKey should be indexed
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.contenttypes  |  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 Asif Saifuddin Auvi):

 considering the model meta refactor and class-based Index and many ORM
 improvement in recent years, what is the best possible solution for this?
 I would to know the recent consensus on 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/067.6f63f4bc9db0f91fcc4632d08754ae1a%40djangoproject.com.


Re: [Django] #25388: Allow disabling of all migrations during tests

2019-11-12 Thread Django
#25388: Allow disabling of all migrations during tests
---+
 Reporter:  Markus Holtermann  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 Jon Dufresne):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * needs_docs:  1 => 0


Comment:

 I took a new approach in PR https://github.com/django/django/pull/12062

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


Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

2019-11-12 Thread Django
#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 From giving a quick look at the current implementation it looks we're
 unfortunately sharing `__fake__` models bound to different `StateApps` for
 performance reason to work around the fact the schema editors are still
 operating from model classes instead of model states #29898.

 Since we'll likely won't be able to prevent this sharing from taking place
 in the short term for performance reasons we should investigate ''why''
 the models cache is not appropriately busted to avoid having two different
 `Options` instances for the `User` model. In this case it looks like the
 `Token` fake model is not reloaded while the `RRset`, `User`, and `Domain`
 ones are when the `AlterField(model_name="RRset")` is performed. That
 makes `Token.user` point to the ''stale'' `User` model and `Domain.owner`
 point to the new one.

 I highly suspect this ticket is related to #27737 and
 
[https://github.com/django/django/blob/b93a0e34d9b9b99d41103782b7e7aeabf47517e3/django/db/migrations/operations/fields.py#L231-L239
 this TODO] in `AlterField.state_forwards`.

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

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


Re: [Django] #30413: admin_views.test_multidb fails with persistent test SQLite database.

2019-11-12 Thread Django
#30413: admin_views.test_multidb fails with persistent test SQLite database.
-+-
 Reporter:  Daniel Hahler|Owner:  Farhaan
 |  Bukhsh
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  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 Farhaan Bukhsh):

 * owner:  Ngalim Siregar => Farhaan Bukhsh


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


Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

2019-11-12 Thread Django
#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hasan, the solution you proposed will likely address this issue but the
 fact multiple instances of `Options` for the same model classes are mixed
 in there is likely a symptom or a larger issue.

 I'm not sure of the origin of it but this can only happen when model from
 different `apps` boundaries are mixed together which should be disallowed
 as it will cause all sort of weird issues. What I mean by that is that
 there's likely ''something'' that creates models from a migration project
 state and have ''real'' models reference them or vice-versa. You can
 assert this doesn't happen by making sure each `model._meta.apps is
 self.apps`.

 In short I think this solution will only temporarily hide a much larger
 problem.

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

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


Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

2019-11-12 Thread Django
#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * has_patch:  0 => 1


Comment:

 Postgres has this issue as well.

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

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


[Django] #30982: error al hacer migraciones

2019-11-12 Thread Django
#30982: error al hacer migraciones
-+
   Reporter:  Danny-Tech |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  2.2
   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  |
-+
 ayuda por favor al hacer las miigraciones para conectarme con postgres me
 sale este error:

 Traceback (most recent call last):
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\utils.py", line 110, in load_backend
 return import_module('%s.base' % backend_name)
   File
 
"C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\importlib\__init__.py",
 line 127, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1006, in _gcd_import
   File "", line 983, in _find_and_load
   File "", line 953, in
 _find_and_load_unlocked
   File "", line 219, in
 _call_with_frames_removed
   File "", line 1006, in _gcd_import
   File "", line 983, in _find_and_load
   File "", line 965, in
 _find_and_load_unlocked
 ModuleNotFoundError: No module named 'django.db.backends.postgresql'

 The above exception was the direct cause of the following exception:

 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 "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\core\management\__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\core\management\__init__.py", line 357, in execute
 django.setup()
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\__init__.py", line 24, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\apps\registry.py", line 114, in populate
 app_config.import_models()
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\apps\config.py", line 211, in import_models
 self.models_module = import_module(models_module_name)
   File
 
"C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\importlib\__init__.py",
 line 127, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1006, in _gcd_import
   File "", line 983, in _find_and_load
   File "", line 967, in
 _find_and_load_unlocked
   File "", line 677, in _load_unlocked
   File "", line 728, in exec_module
   File "", line 219, in
 _call_with_frames_removed
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\contrib\auth\models.py", line 2, in 
 from django.contrib.auth.base_user import AbstractBaseUser,
 BaseUserManager
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\contrib\auth\base_user.py", line 47, in 
 class AbstractBaseUser(models.Model):
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\models\base.py", line 117, in __new__
 new_class.add_to_class('_meta', Options(meta, app_label))
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\models\base.py", line 321, in add_to_class
 value.contribute_to_class(cls, name)
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\models\options.py", line 204, in contribute_to_class
 self.db_table = truncate_name(self.db_table,
 connection.ops.max_name_length())
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\__init__.py", line 28, in __getattr__
 return getattr(connections[DEFAULT_DB_ALIAS], item)
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\utils.py", line 201, in __getitem__
 backend = load_backend(db['ENGINE'])
   File "C:\Users\PC\AppData\Local\Programs\Python\Python37-32\lib\site-
 packages\django\db\utils.py", line 125, in load_backend
 ) from e_user
 django.core.exceptions.ImproperlyConfigured:
 'django.db.backends.postgresql' isn't an available database backend.
 Try using 'django.db.backends.XXX', where XXX is one of:
 'mysql', 'oracle', 'sqlite3'
 PoCode\Django\TiendaOnline>
 PS C:\Users\PC\Desktop\Daniel\visualStudioCode\Django\TiendaOnline> python
 manage.py makemigrations
 Traceback (most recent call last):
   File 

Re: [Django] #29926: Python 3.8 compatibility

2019-11-12 Thread Django
#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"622158b371ade0e76e84d93ce18fc8caef911d22" 622158b3]:
 {{{
 #!CommitTicketReference repository=""
 revision="622158b371ade0e76e84d93ce18fc8caef911d22"
 [2.2.x] Refs #29926 -- Doc'd Python 3.8 compatibility in Django 2.2.x.

 Backport of b93a0e34d9b9b99d41103782b7e7aeabf47517e3 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.c72857f8c85606a1e1fffbe44c4692fd%40djangoproject.com.


Re: [Django] #29926: Python 3.8 compatibility

2019-11-12 Thread Django
#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"9ad38d4089dafaf6574a51bc804e963b7fdb8eb1" 9ad38d40]:
 {{{
 #!CommitTicketReference repository=""
 revision="9ad38d4089dafaf6574a51bc804e963b7fdb8eb1"
 [3.0.x] Refs #29926 -- Doc'd Python 3.8 compatibility in Django 2.2.x.

 Backport of b93a0e34d9b9b99d41103782b7e7aeabf47517e3 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.b894424eb54c0926603a1f78fbbc3227%40djangoproject.com.


Re: [Django] #29926: Python 3.8 compatibility

2019-11-12 Thread Django
#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 GitHub ):

 In [changeset:"b93a0e34d9b9b99d41103782b7e7aeabf47517e3" b93a0e3]:
 {{{
 #!CommitTicketReference repository=""
 revision="b93a0e34d9b9b99d41103782b7e7aeabf47517e3"
 Refs #29926 -- Doc'd Python 3.8 compatibility in Django 2.2.x.
 }}}

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


Re: [Django] #29926: Python 3.8 compatibility

2019-11-12 Thread Django
#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"cc3516dc4fe0731ceada2f1b1ae41d57e31817a7" cc3516dc]:
 {{{
 #!CommitTicketReference repository=""
 revision="cc3516dc4fe0731ceada2f1b1ae41d57e31817a7"
 [2.2.x] Refs #29926 -- Added Python 3.8 to classifiers and tox.ini.

 Backport of 37f02c47f8eb4d6e7b3c22401dba57b00780dc5d 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.fe9ec24e6bc69aeab38be2fcbc103ac9%40djangoproject.com.


Re: [Django] #29926: Python 3.8 compatibility

2019-11-12 Thread Django
#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"8eda248dc9be2da93ff470567ec3291ac51179e3" 8eda248d]:
 {{{
 #!CommitTicketReference repository=""
 revision="8eda248dc9be2da93ff470567ec3291ac51179e3"
 [2.2.x] Refs #29926 -- Bumped minimum tblib version to 1.5.0 in test
 requirements.

 Backport of 25903e41fb45ce9cc80dc93bf4b51ea431dcb2b6 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.7c9030de538f75e16979784a1440a88e%40djangoproject.com.


Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

2019-11-12 Thread Django
#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Simon Charette):

 I think that there's enough points being raised in both camps to warrant a
 discussion on the developer mailing list before reverting this change.

 Since 2f010795e690550c8c6f56b3924c0f629cacb33b is not part of any release
 branch we should take the time to discuss this change with a wider
 audience before taking a decision.

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

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


Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

2019-11-12 Thread Django
#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Sergey Fedoseev):

 * needs_tests:  0 => 1


Comment:

 I'm opposed to reverting, but if we end with it, the tests are needed.

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

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


Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

2019-11-12 Thread Django
#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   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 Sergey Fedoseev):

 Replying to [comment:14 felixxm]:

 > we're not able to propose any alternative solution

 We don't have to, since the laziness itself of `request.user` is not
 documented.

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

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


Re: [Django] #30981: Admin changelist crashes when using query expression in the ModelAdmin's admin_order_field

2019-11-12 Thread Django
#30981: Admin changelist crashes when using query expression in the ModelAdmin's
admin_order_field
---+--
 Reporter:  Petr Dlouhý|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  2.2
 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 Petr Dlouhý):

 Note: this is motivated by usage with `nulls_last` such as
 `F('sum_amount').desc(nulls_last=True)`, which does throw a different
 traceback:


 {{{
 Traceback (most recent call last):
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/core/handlers/exception.py",
 line 34, in inner
 response = get_response(request)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/core/handlers/base.py", line
 115, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/core/handlers/base.py", line
 113, in _get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/options.py",
 line 606, in wrapper
 return self.admin_site.admin_view(view)(*args, **kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/utils/decorators.py", line
 142, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/views/decorators/cache.py",
 line 44, in _wrapped_view_func
 response = view_func(request, *args, **kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/sites.py", line
 223, in inner
 return view(request, *args, **kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/utils/decorators.py", line 45,
 in _wrapper
 return bound_method(*args, **kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/utils/decorators.py", line
 142, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/options.py",
 line 1672, in changelist_view
 cl = self.get_changelist_instance(request)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/options.py",
 line 744, in get_changelist_instance
 sortable_by,
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/views/main.py",
 line 81, in __init__
 self.queryset = self.get_queryset(request)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/views/main.py",
 line 436, in get_queryset
 qs = qs.order_by(*ordering)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/db/models/query.py", line
 1074, in order_by
 obj.query.add_ordering(*field_names)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/db/models/sql/query.py", line
 1804, in add_ordering
 if not hasattr(item, 'resolve_expression') and not
 ORDER_PATTERN.match(item):
 TypeError: expected string or bytes-like object

 }}}

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


Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

2019-11-12 Thread Django
#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * status:  new => assigned
 * owner:  nobody => Hasan Ramezani


Comment:

 I investigate it and think the problem comes from  this line:

 {{{
 
related_objects_graph[f.remote_field.model._meta.concrete_model._meta].append(f)
 }}}
 of
 
[https://github.com/django/django/blob/30359496a3f3d9af0b02afc334710f7e24c74f5b/django/db/models/options.py#L685
 django.db.models.options.Options._populate_directed_relation_graph()]:

 I added some log to check `related_objects_graph` in bothe case.
 When the migration runs by `./manage.py migrate desecapi 0001` and then
 `./manage.py migrate desecapi 0002` (correct case), here is the result:


 {{{
 defaultdict(, {:
 [,
 ], :
 []})
 }}}


 But, When the migration runs by `./manage.py migrate desecapi 0002` (case
 with problem),  here is the result:


 {{{
 defaultdict(, {:
 [], :
 [], : []})
 }}}

 From the result, it is obvious that in the first case we have the
 `` key with a value of type list with two items
 `[,
 ]`.
 which generate two alter commands:


 {{{
 ALTER TABLE `app1_domain` DROP FOREIGN KEY
 `app1_domain_owner_id_cc7262a2_fk_app1_user_id`
 ALTER TABLE `app1_token` DROP FOREIGN KEY
 `app1_token_user_id_5ea51092_fk_app1_user_id`
 }}}

 But in the second case, we have two keys ``  which one
 of them has a value of type list with one item
 `[]`
 and the other has a value of type list with one item
 `[]`.

 which generate just one alter command:

 {{{
 ALTER TABLE `app1_domain` DROP FOREIGN KEY
 `app1_domain_owner_id_cc7262a2_fk_app1_user_id`
 }}}

 Thus, the second foreign key `app1_token_user_id_5ea51092_fk_app1_user_id`
 still remains and cause the error.

 Any suggestions for a fix?

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

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


[Django] #30981: Admin changelist crashes when using query expression in the ModelAdmin's admin_order_field

2019-11-12 Thread Django
#30981: Admin changelist crashes when using query expression in the ModelAdmin's
admin_order_field
-+
   Reporter:  Petr Dlouhý|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  2.2
   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  |
-+
 When I use `admin_order_field` with F() expression or any other type of
 expression that doesn't have `as_sql` such as:

 {{{
 class UserProfileAdmin(admin.ModelAdmin):
 def get_sum_amount(self, obj):
   return obj.sum_amount
   get_sum_amount.admin_order_field = F('sum_amount')

 }}}

 I got the following crash:


 {{{
 Traceback (most recent call last):
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/template/base.py", line 835,
 in _resolve_lookup
 return self.get_fields()
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/views/main.py",
 line 81, in __init__
 self.queryset = self.get_queryset(request)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/views/main.py",
 line 435, in get_queryset
 ordering = self.get_ordering(request, qs)
   File "/home/petr/.local/share/virtualenvs/aklub_project-
 HrPEZ5ak/lib/python3.6/site-packages/django/contrib/admin/views/main.py",
 line 296, in get_ordering
 elif order_field.startswith('-') and pfx == '-':
 AttributeError: 'F' object has no attribute 'startswith'
 }}}

 This is similar issue like https://code.djangoproject.com/ticket/28958 but
 wasn't fixed by the 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/053.2d7d498d73863a40ad5bc8aca6cc74b2%40djangoproject.com.


Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

2019-11-12 Thread Django
#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   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 Nick Pope):

 I'd not really been following along, so just caught up on the comments
 here.

 If we revert, then I honestly think that this should be documented. Or at
 least have a comment in the code to say that this is going to be supported
 for third-parties and shouldn't be removed.

 

 I've got to be honest and say if you're going to use code that is
 **clearly** marked as private - ''that is the underscore prefix convention
 in Python'' - you've got what's coming to you and you haven't got a leg to
 stand on. Yes, it doesn't stop me either, but I would accept that I'm in
 the wrong and will have to deal with the fallout. In addition, as
 highlighted above, many of the cases are copy-paste from Django's own
 code. That is just sloppy and if encouraged, or at least not discouraged,
 no changes would ever be possible because "someone might have copied it
 and used it" in a way that was never intended.

 To quote the Python [https://docs.python.org/3/tutorial/classes.html
 #private-variables documentation]:

 > “Private” instance variables that cannot be accessed except from inside
 an object don’t exist in Python. However, there is a convention that is
 followed by most Python code: a name prefixed with an underscore (e.g.
 `_spam`) should be treated as a non-public part of the API (whether it is
 a function, a method or a data member). **It should be considered an
 implementation detail and subject to change without notice.**

 I also don't really understand why `hasattr()` checks are needed here in
 other middlewares. My question wasn't answered. Surely you just need to
 access `request.user` if you need the user object and if you don't, you
 don't. If this is to check whether we've called this and thus assigned
 `request.user` prior to using that elsewhere, then it sounds like a
 middleware ordering problem. Or not subclassing a middleware properly.

 > Grrr. I think it's
 [https://github.com/search?l=Python=_cached_user=Code more than
 sometimes...]. 

 I find GitHub code search to be dreadful. It doesn't provide capability to
 filter out partial paths. Yes that says 53K+ results, but the vast
 majority seem to be vendored copies of Django and other projects that have
 copied bits of Django and then been vendored themselves which will,
 frankly, not be affected.

 > The user has been cached on the request here for 13 years.

 Just because something is old, that doesn't mean it shouldn't necessarily
 change.

 > Exactly this. Custom middleware's leveraging `_cached_user` but not
 setting a `user` that has `_wrapped` property... (and so on).

 I was merely suggesting an example to complement proposals in other
 comments, but posited whether we actually wanted to do this as we'd have
 to document `LazyObject` which is currently private. (That is another
 private thing that unfortunately bleeds across public interfaces, notably
 in lazy translations.)

 

 Anyway, this is a relatively small change so it isn't something that is
 the end of the world and I won't get in the way of it if the majority want
 to revert. I just have a different view that progress shouldn't be stymied
 just because something has always been that way, is old (and thus
 venerated?), or because people broke convention and thus we need to
 capitulate and accept all "bad" behaviour. Yes, there is not breaking
 backward compatibility, but that is different to not breaking something
 where backward compatibility was never guaranteed.

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

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


[Django] #30980: admin.E130 (duplicate __name__ attributes of actions) should specify which were duplicated

2019-11-12 Thread Django
#30980: admin.E130 (duplicate __name__ attributes of actions) should specify 
which
were duplicated
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |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 |
+
 The fact that the `__name__` is used is somewhat an implementation detail,
 and there's no guarantee the user has enough of an understanding of python
 to know what that attribute is, let alone how to fix it.

 This just came up on IRC because a user had defined `actions =
 [delete_selected]` where `delete_selected` was a reference to their own
 callable, but shares the name of the base one (and by specifying the
 `actions = ` they were assuming that they were wholesale replacing the
 actions list, where that may not be true for site-wide actions) so errored
 ... but they only had define a list of `len(...) == 1` so how can there be
 a duplicate (is their thought process)?

 The error message should specify those names that occur 2> (rather than
 just check `len(...)` vs `len(set(...))`), and ought ideally to explain
 where the duplicate comes from (ie: AdminSite-wide).

 Related ticket about E130: #30311 (+ those it references) but is about the
 replacement strategy rather than the error message itself.

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


Re: [Django] #30828: Document how to add ManyToMany relationships in bulk for different objects and for manually defined "through".

2019-11-12 Thread Django
#30828: Document how to add ManyToMany relationships in bulk for different 
objects
and for manually defined "through".
-+-
 Reporter:  David Foster |Owner:  David
 Type:   |  Foster
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"afde973061a3e6477f3c454f4471842d37e73494" afde9730]:
 {{{
 #!CommitTicketReference repository=""
 revision="afde973061a3e6477f3c454f4471842d37e73494"
 [2.2.x] Fixed #30828 -- Added how to remove/insert many-to-many relations
 in bulk to the database optimization docs.

 Backport of 6a04e69e686cf417b469d7676f93c2e3a9c8d6a3 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.2e0116f4d7e0ba31b34a7541d1f1b40a%40djangoproject.com.


Re: [Django] #30828: Document how to add ManyToMany relationships in bulk for different objects and for manually defined "through".

2019-11-12 Thread Django
#30828: Document how to add ManyToMany relationships in bulk for different 
objects
and for manually defined "through".
-+-
 Reporter:  David Foster |Owner:  David
 Type:   |  Foster
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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:"6a04e69e686cf417b469d7676f93c2e3a9c8d6a3" 6a04e69e]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a04e69e686cf417b469d7676f93c2e3a9c8d6a3"
 Fixed #30828 -- Added how to remove/insert many-to-many relations in bulk
 to the database optimization docs.
 }}}

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

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


Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

2019-11-12 Thread Django
#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   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):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/12057 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/072.a3bdd1ba5c98b2f01496fbeaa64e4e07%40djangoproject.com.


Re: [Django] #30405: IndexError in _get_lines_from_file when module does not match file contents (via loader)

2019-11-12 Thread Django
#30405: IndexError in _get_lines_from_file when module does not match file 
contents
(via loader)
-+-
 Reporter:  Daniel Hahler|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  2.2
 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:"e8de188c06823ed5c574778dc1e47f035d7d0bf9" e8de188c]:
 {{{
 #!CommitTicketReference repository=""
 revision="e8de188c06823ed5c574778dc1e47f035d7d0bf9"
 Refs #30405 -- Added ExceptionReporter._get_source().
 }}}

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


Re: [Django] #30405: IndexError in _get_lines_from_file when module does not match file contents (via loader)

2019-11-12 Thread Django
#30405: IndexError in _get_lines_from_file when module does not match file 
contents
(via loader)
-+-
 Reporter:  Daniel Hahler|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  2.2
 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:"4b78546ef19b93c02c60806c065e4560ee4fbee3" 4b78546e]:
 {{{
 #!CommitTicketReference repository=""
 revision="4b78546ef19b93c02c60806c065e4560ee4fbee3"
 Fixed #30405 -- Fixed source code mismatch crash in ExceptionReporter.
 }}}

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