plumdog / django_migration_testcase Goto Github PK

Sorry for my ignorance, but does this handle / keep / restore data being created during migrations?

The typical problem is that Django's flush (called with TransactionTestcase) will empty the tables, but keeps their structure migrated (see pytest-dev/pytest-django#220 (comment) for more information / discussion in this regard), and migrations won't be run again (the migrations table/info is kept).

I just came across this - thanks for the good work.

I think you can easily combine test_app_south and test_app for a little DRYer code, because all new versions of south actually start looking for the migrations in 'south_migrations' directory first. That allows you to maintain the same django package with both South migrations and django 1.7+ migrations.

See http://south.readthedocs.org/en/latest/releasenotes/1.0.html 'Library migration path'

I've got an app with two databases

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'dayjob',
    },
    'staticpages_db': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'dayjob_staticpages_db',
    },
}

If I want to run migrations against staticpages_db, I have to modify migrate_kwargs like so

    def migrate_kwargs(self):
        kwargs = super().migrate_kwargs()
        kwargs['database'] = 'staticpages_db'
        return kwargs

This is simple to do, but not how I would expect multiple database support to be handled. That expectation being that when django_migration_testcase encounters the multi_db setting

class DayJobPrivateRepoTest(MigrationTest):
    multi_db = True

It runs the migrations across all available databases. This would mimic the behavior of django's built-in test functions.

I'm more than happy to implement this myself @plumdog! Lemme know what you think

If we have app1 and app2, maybe we need to test what happens when we migration from app1.0001 and app2.0001 to app2.0002 and app2.0002, eg for testing dependencies.

The above should probably become something like

class MyDoubleMigrationTest(MigrationTest):
    before = [('app1', '0001_initial'), ('app2', '0001_initial)]
    after = [('app1', '0002_second'), ('app2', '0002_second')]

These have to be ordered because we have to decide in which order we issue the migrate commands.

In this situation, should also raise an exception if you run something like self.get_model_before('MyModel') because it's ambiguous as to which app's model you are referring to.

When running tests with Django 2 there is an incompatibility with the new migrate command line.

It appears that no_initial_data is not a valid argument anymore.

TypeError: Unknown option(s) for migrate command: no_initial_data. Valid options are: app_label, database, fake, fake_initial, help, interactive, migration_name, no_color, no_input, pythonpath, run_syncdb, settings, skip_checks, stderr, stdout, traceback, verbosity, version.

The source

    def migrate_kwargs(self):
        return {'verbosity': 0,
                'no_initial_data': True, # <=== THIS CAUSES THE ERROR
                'interactive': False}

    def migrate(self, app_name, version, fake=False):
        kwargs = self.migrate_kwargs()
        kwargs['fake'] = fake
        # For Django 1.7 - does a len() check on args.
        if version:
            args = ('migrate', app_name, version)
        else:
            args = ('migrate', app_name)
        call_command(*args, **kwargs)  # <=== CRASHES HERE

What do you recommend to fix the issue?

I do not find anything about no_initial_data in the documentation of django 1.7 to 2.0.

Do you remember why it was added?

Not sure what to do about this since there is nothing about this in django upgrade guide.

What should we do:
-Remove it?
-Add condition to add it only prior to 2.0?

If I ask for a migration state that is disallowed, should error, rather than carrying on and getting it wrong.

Eg, if app1 has two migrations, 0001, 0002
And app2 has a migration 0001, that depends on app1.0002

If I set before = [('app1', '0001'), ('app2', '0002')] then I am asking for something that cannot happen.

What will happen at present is that we just run the migrate commands sequentially. In affect:

django migrate app1 0001
django migrate app2 0002

Which will just end us up with app1 being at 0002, which is not what was asked for. This will require some digging around, because django doesn't (I believe) let you specify multiply targets when migrating.

Should be able to migrate right back to the start so you can test initial migrations.

Let assume we want a migration to rather fail when the data is not correct (Ex: require human intervention to fix the data) and we want to test that.

1. We create test data
2. Call self.run_migration()
3. Migration throws exception
4. We catch the exception and validate the data migration had no effect, test succeeds so far (everything is fine so far)
5. Then teardown run and exception is thrown. Test fail.
6. Database is now in a bad state

The teardown of MigrationTest will run the migration again to restore the previous state of the migration which will fail since the test data will be still there.

The workaround is to do the teardown of the data ourself but it is impractical, I would assume MigrationTest would clear the test data before to roll the migrations.

Assumed based on

Can get models from other apps with self.get_model_before('otherapp.OtherModel')

And your tests didn't catch this!

I came across a weird behavior with trying to use ForeignKey models in migrations. I pushed a commit (percipient@9a3d324) that illustrates it with a failing test.

Pretty much if you have a ForeignKey and attempt to create a new instance of a model (after using get_model_before or get_model_after), you get strange errors about the objects not being the correct type to add as a FK.

The results of running the added tests in that commit (I only ran SQLite, I don't have PostgreSQL installed):

Tests for tests/test_project_sqlite_django
Creating test database for alias 'default'...
...E.F...
======================================================================
ERROR: test_migration (test_app.tests.ForeignKeyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "django_migration_testcase/tests/test_project_sqlite_django/test_app/tests.py", line 134, in test_migration
    foreign = ForeignModel(name='test_foreign', my=my)
  File "~/.virtualenvs/django_migration_testcase/lib/python2.7/site-packages/django/db/models/base.py", line 468, in __init__
    setattr(self, field.name, rel_obj)
  File "~/.virtualenvs/django_migration_testcase/lib/python2.7/site-packages/django/db/models/fields/related.py", line 635, in __set__
    self.field.rel.to._meta.object_name,
ValueError: Cannot assign "<MyModel: MyModel object>": "ForeignModel.my" must be a "MyModel" instance.

======================================================================
FAIL: test_migration_clearly (test_app.tests.ForeignKeyTest)
A clear illustration of the problem.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "django_migration_testcase/tests/test_project_sqlite_django/test_app/tests.py", line 167, in test_migration_clearly
    self.assertEqual(MyModel, MyModel2)
AssertionError: <class 'MyModel'> != <class 'MyModel'>

----------------------------------------------------------------------
Ran 9 tests in 1.449s

FAILED (failures=1, errors=1)

I've tried printing out additional information in test_migration_clearly, but as far as I can tell they are the same class.

I'm not 100% sure this is a bug, maybe I'm just doing something silly, but I've spent a bit of time on this and have been unable to figure it out. Any help would be appreciated!

I would like to use your great package, but unfortunately my project needs to maintain backwards compatibility with Py3.5.

What are the reasons 3.5 is not supported (e.g. which 3.6 features are used?).
How hard would it be to port it to 3.5?

MigrationTestCase should track if it has been migrated and error if the wrong get_model_(before|after) is called.

Related to #13

I got his error:

File "/usr/local/lib/python3.5/site-packages/django/db/migrations/executor.py", line 218, in unapply_migration
    state = migration.unapply(state, schema_editor)
  File "/usr/local/lib/python3.5/site-packages/django/db/migrations/migration.py", line 146, in unapply
    raise IrreversibleError("Operation %s in %s is not reversible" % (operation, self))
django.db.migrations.exceptions.IrreversibleError: Operation <RunPython <function move_Point at 0x7feb316df730>> in my_app.0008_move_message_point_to_device_location is not reversible

this move_point method is a personal migration method that move data.
May i need to make a reverse method of it ?

I have cloned it and try to run setup. This is the result:

/tmp/django_migration_testcase$ python setup.py
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help

error: no commands supplied

And just some more validation around this wouldn't hurt.

I think this means that I didn't actually full fix #12

Related:

Does TransactionTestCase take care of this?
If not, is there something we can do to dump and restore the database everytime/when needed?