Opened 22 months ago

Closed 21 months ago

Last modified 14 months ago

#23347 closed New feature (needsinfo)

Add --dry-run to migrate

Reported by: Naddiseo Owned by: nobody
Component: Migrations Version: 1.7-rc-3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


In a similar vein to, I would like to propose that a "--dry-run" or "--check" be added to the migrate command. Basically, I want to be able to run through the migrations without it making database changes, so that I can see if I've broken something, especially if I'm writing a migration with a RunPython.

Another way I can see this working, is if sqlmigrate could also output all the sql that was issued, including those issued by RunPython, so that if I had the following migration [0] it would output something similar to [1]

[0] Migration:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations

def update_contenttypes(apps, schema_editor):
        ContentType = apps.get_models('contenttypes', 'ContentType')
        ContentType.objects.get(pk = 1)

class Migration(migrations.Migration):
        dependencies = [
                ('everdeal', '0001_initial'),
        operations = [

[1] Output:

-- Raw Python operation
SELECT * FROM contenttypes_contenttype WHERE id=1;


Change History (7)

comment:1 Changed 21 months ago by timgraham

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to needsinfo
  • Status changed from new to closed

I don't see a way to implement what you propose. I don't think there is a way to output SQL for arbitrary RunPython without actually running it as queries may dependent on each other (for example manipulating models in a loop of MyModel.objects.all()). If you have an idea, please provide it (or a patch).

comment:2 Changed 21 months ago by Naddiseo

Maybe my understanding of databases is wrong, but couldn't you create a savepoint at the beginning, do all the migrations - including the RunPython - then issue a rollback at the end?

comment:3 Changed 21 months ago by charettes

@Naddiseo unfortunately not all supported backends support transactional DDL which might end up committing the active transaction silently.

We can't assume only SQL will be executed by RunPython given the provided schema_editor.

comment:4 Changed 21 months ago by timgraham

(Was about to make a similar comment as @charettes.)

As for alternatives: I don't quite understand your use case "so I can see if I've broken something." Migrations are executed when you run tests so you could test it there. Also the migration is executed in a transaction, so if it breaks somewhere in the middle, any changes should be rolledback. Maybe you could elaborate why either of these options aren't sufficient.

comment:5 Changed 21 months ago by Naddiseo

Also the migration is executed in a transaction, so if it breaks somewhere in the middle, any changes should be rolledback.

Unless it's a backend that doesn't support transactions?

My "use case" is that I like to do incremental testing while I'm developing - and by testing, I don't mean test cases, I mean running the code to see if it doesn't have runtime errors - so if I'm writing a data migration, I may right a small section of it, then run the migration to see if what I have works, then move on to the next part, but I don't want the database to be changed when I run it again. Currently, I can work around this by raising an Exception to force a rollback; providing a "dry-run" option would, for me, be a preferable approach, and providing the would-be committed sql would aid in any kind of debugging where looking at the sql is necessary.

I guess if not all of the backends support transactions, then I guess this can't really be done (cleanly anyway), and this ticket can be resolved. Thanks for your time.

comment:6 Changed 15 months ago by Suor

This would be use full even without RunPython support. I used this feature a lot in south.

comment:7 Changed 14 months ago by MarkusH

If you want to see the particular SQL code generated for a migration you can use sqlmigrate

Note: See TracTickets for help on using tickets.
Back to Top