I wanted to use sqlall and other commands to diff my existing DB with the
"theoretical" one, but django refused, indicating that only sqlmigrate and
sqlflush were allowed for apps with migrations. I had to redeploy another
install from scratch to do the diff.
Wouldn't it be better to issue a warning in these cases, but let the
developper use these tools to understand what's wrong, and manually "fake"
migrations when stuffs are out of control ?
--
Ticket URL: <https://code.djangoproject.com/ticket/24481>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I think those commands can't work like they did before because when there
are multiple migrations, I don't think it's feasible to determine what the
resulting database schema will look like.
Maybe an idea would be to make the `migration_name` argument to
`sqlmigrate` optional so that you could do `sqlmigrate <app_name>` to get
the SQL for all of your migrations in an app. I guess we might be able to
make `app_name` optional as well so that `sqlmigrate` could easily output
the SQL for all migrations of all apps.
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:1>
Comment (by pakal):
Do you mean "sqlmigrate" would output, in sequence, all "alter tables"
commands to recreate the final DBs ?
I've had a look at django\core\management\sql.py, a function
check_for_migrations() is called to abort when some models use migrations,
but other than that, nothing seems to prevent generation from sql for
migration-enabled models. There is even, farther, code which looks
explicitely dedicated to migration handling ("for model in
router.get_migratable_models(app_config, connection.alias,
include_auto_created=True)").
From what I understand, these sql* commands browse '''current''' model
objects, and convert them to sql statements, so I guess they shouldn't
care about whether these python classes have some "history" behind them.
Or am I misunderstanding how all that works ?
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:2>
* version: 1.7 => master
* type: Bug => New feature
* stage: Unreviewed => Accepted
Comment:
It might work. Would be happy to look at a patch but might have to close
this if it ends up being confusing or not feasible to implement.
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:3>
Comment (by pakal):
Looked at the master-branch code, all the code for these commands has
disappeared from it, however it'd really be worth to resurrect the
"sqlcreate" command only, it's invaluable for quick debugging of migration
troubles.
I'll start a thread on the mailing-list to see what's the status about all
this.
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:4>
* status: new => assigned
* owner: nobody => raulcd
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:5>
* has_patch: 0 => 1
Comment:
PR at:
https://github.com/django/django/pull/4374
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:6>
* status: assigned => new
* owner: raulcd =>
* has_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:7>
Comment (by andrewgodwin):
I've started working on this here:
https://github.com/django/django/pull/4729
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:5>
Comment (by MarkusH):
Andrew, Loic, Florian and I came up with the following list of features we
want `sqlmigrate` to support:
* just one migration
* list of migration names
* start / end of migration graph
* ignore migrations and build straight from models
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:6>
* owner: nobody => andrewgodwin
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:7>
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:8>
* owner: Andrew Godwin => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/24481#comment:9>