2

In my Django app, I want to add a couple of fields to my existing models and possibly create a new class. I just want to test the new feature and approve if it works.

I can revert the code using git easily. But if I make a makemigrations+migrate then my MySQL database will change and reversing the changes looks like manual deletion of tables and reverting to an old state using a command like django-admin migrate [app_label] [migration_name] (In some cases it looks really cumbersome, example).

I'm wondering if there is any safe practice to try manipulating the database and revert it back to it's initial state safely.

Community
  • 1
  • 1
HBat
  • 4,873
  • 4
  • 39
  • 56
  • 2
    If you only have schema migration you just have to roll your migrations back - the answer you linked to is just plain hogwash BTW, the poster must have done a terrible mess of his migrations if he ever had to do what he describes. If you have data migrations too then you obviously need to take care to make them reversible (wite both the 'up' and 'down' migration code). FWIW I have been doing just this for years now (since South became available actually) without any problem. Never had to "manually" delete anything nor mess with my migration files. – bruno desthuilliers Apr 20 '17 at 13:56
  • it may look cumbersome. but it won't mess up anything.. – Asthme Apr 20 '17 at 14:02
  • 2
    Why not simply duplicate your DB? – albar Apr 20 '17 at 14:12

1 Answers1

1

Probable solution #1:

You can utilize the test database that gets created when using django.test.TestCase:

Tests that require a database (namely, model tests) will not use your “real” (production) database. Separate, blank databases are created for the tests.

Create some unit tests for your project and make your migrations (without migrating to your production DB, just keep the migrations). Then:

If the database does not exist, it will first be created. Any migrations will also be applied in order to keep it up to date.

Usually, the database gets destroyed at the end of your tests, but you can keep it between runs:

You can prevent the test databases from being destroyed by using them test --keepdb option. This will preserve the test database between runs.

With this trick you can test every migration you make in a fake DB and when you do finalize your model and you have all the migrations history complete, you can migrate on your production DB.

Probable solution #2:

You can make a copy of your database as @albar suggests and have it as a back up while you are working on your new migrations.

Break stuff as much as you want and when you are set and done, replace the "battered" DB with your back up and apply your migration history to it.

John Moutafis
  • 22,254
  • 11
  • 68
  • 112
  • The first solution is partially what I'm looking for. The only tricky part is creating those unit tests. It is a hassle, especially if I decide to not go with the changes. Also, I might not see the effects of it except the testing environment as far as I understand. Possibly, I'm going with the second solution, but will look for a method as easy as `git revert ` for databases. – HBat Apr 20 '17 at 20:16
  • Well if you create good unit tests, you can check the integrity of your project on every change that you make (not only on model changes as well), which is really helpful in the long run. – John Moutafis Apr 20 '17 at 20:19