[Django] #24412: Red migration notice should be printed when running tests without --verbosity=2
Django
--verbosity=2
-------------------------------+-----------------------
Reporter: pzrq | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.8alpha1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+-----------------------
The following quite useful red NOTICE is printed to the command line only
when running `manage.py test --verbosity=2 --keepdb` (the second time
after no migrations are run), and thus buried amongst a lot of other
information:
https://github.com/django/django/blob/master/django/core/management/commands/migrate.py#L183-191
Your models have changes that are not yet reflected in a migration, and
so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run
'manage.py migrate' to apply them.
I think it should be print at the default `manage.py test` (i.e.
`--verbosity=1`).
This might be complicated by decrementing the verbosity by 1 when calling
`migrate` inside `create_test_db`:
https://github.com/django/django/blob/master/django/db/backends/base/creation.py#L68
Though there are only 16 verbosity strings in `migrate.py` (including
calls to showmigrations and emit_pre_migrate_signal) so the side effects
from that part should be reasonably traceable.
Not sure about not printing the first time (i.e. without `--keepdb`) ...
any thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/24412>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
--verbosity=2
Reporter: pzrq | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.8alpha1
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 pzrq):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> The following quite useful red NOTICE is printed to the command line only
> when running `manage.py test --verbosity=2 --keepdb` (the second time
> after no migrations are run), and thus buried amongst a lot of other
> information:
> https://github.com/django/django/blob/master/django/core/management/commands/migrate.py#L183-191
>
> Your models have changes that are not yet reflected in a migration, and
> so won't be applied.
> Run 'manage.py makemigrations' to make new migrations, and then re-run
> 'manage.py migrate' to apply them.
>
> I think it should be print at the default `manage.py test` (i.e.
> `--verbosity=1`).
>
> This might be complicated by decrementing the verbosity by 1 when calling
> `migrate` inside `create_test_db`:
> https://github.com/django/django/blob/master/django/db/backends/base/creation.py#L68
>
> Though there are only 16 verbosity strings in `migrate.py` (including
> calls to showmigrations and emit_pre_migrate_signal) so the side effects
> from that part should be reasonably traceable.
>
> Not sure about not printing the first time (i.e. without `--keepdb`) ...
> any thoughts?
New description:
The following quite useful red NOTICE is printed to the command line only
when running `manage.py test --verbosity=2 --keepdb` (the second time
after no migrations are run), and thus buried amongst a lot of other
information:
https://github.com/django/django/blob/master/django/core/management/commands/migrate.py#L183-191
Your models have changes that are not yet reflected in a migration, and
so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run
'manage.py migrate' to apply them.
I think it should be printed at the default `manage.py test` (i.e.
`--verbosity=1`).
This might be complicated by decrementing the verbosity by 1 when calling
`migrate` inside `create_test_db`:
https://github.com/django/django/blob/master/django/db/backends/base/creation.py#L68
Though there are only 16 verbosity strings in `migrate.py` (including
calls to showmigrations and emit_pre_migrate_signal) so the side effects
from that part should be reasonably traceable.
Not sure about not printing the first time (i.e. without `--keepdb`) ...
any thoughts?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24412#comment:1>
Django
--verbosity=2
Reporter: pzrq | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* version: 1.8alpha1 => master
* type: Uncategorized => New feature
* stage: Unreviewed => Accepted
Comment:
We don't accept any feature requests for 1.8 anymore, but I accepted it
for the next version.
--
Ticket URL: <https://code.djangoproject.com/ticket/24412#comment:2>
Django
--verbosity=2
Reporter: pzrq | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by pzrq):
Thanks Markus, it is consistent with the 1.8 roadmap and the workaround is
to watch closely `--verbosity=2 --keepdb`
https://code.djangoproject.com/wiki/Version1.8Roadmap
--
Ticket URL: <https://code.djangoproject.com/ticket/24412#comment:3>
Django
--verbosity=2
Reporter: pzrq | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* status: new => closed
* resolution: => duplicate
Comment:
This will be fixed by #24484
--
Ticket URL: <https://code.djangoproject.com/ticket/24412#comment:4>