Why use South during initial development?

Question

I'm wondering about the advantages of using (django) South during heavy initial development of a project.

At the early stages of development there's normally rapid model changing, frequent branching and merging (especially if you use a development strategy like git-flow) and very little, if any, stored data. Why would you want to keep of these initial model changes? What are the advantages/disadvantages?

I'm under the impression that it's easier to wait until the development settles down (and you have data you actually want to keep) before activating South and performing an initial migration. Is it possible to do that? Would you want to do that?

Answer 1

It definitely is possible to use south from a certain stage on and do an initial migration. SOuth docs here: http://south.aeracode.org/docs/tutorial/part1.html#converting-existing-apps

I do use south during development, as i often have data that i use to test the UI or such things. South is also very helpful in keeping your database consistent if you do not start with a complete new database after every model change. Therefor i agree with meder too, it would be great if Django would have that schema migration, on the other hand it doesn't matter that much as south is very easy to implement.

Answer 2

Good news - as of 2nd September 2014 migrations are now part of core Django, release 1.7.

https://docs.djangoproject.com/en/dev/releases/1.7/

I was just about to install South, and now I don't have to. Hope this gives a useful heads-up to other users in the same situation.

Answer 3

As soon as I am about push a commit that other people need to use, I create a migration so they can still have a working copy.

If you are working alone(and not worrying about deployment), this is not an issue and you can wait until the last possible moment to create a migration.

Once you begin working with others, it makes life easier to quickly make migrations so it becomes a workflow habit and everyone is on the same database page.

Also, syncdb is not an option if you are simply modifying a field. It gets incredibly annoying to have to blow away a table just for adding, deleting or modifying fields.

If I have a bunch of schema migrations that I added, sometimes I will combine them(rollback and delete them and create a new jumbo migration) into a single migration. But normally, the number of migrations doesn't bother me because they don't cost me anything really.

Answer 4

I've found South to be just as useful during development as afterwards, precisely because the table fields are changing so often. It's pretty annoying to have to drop a table and re-create it with syncdb just to add one field, especially if you have any test data at all. (You could also just modify the table directly in your DBMS, but then you have to be careful to use the same field type that Django is expecting, set the attributes like ON DELETE appropriately, etc.). Plus if anyone else is working on the project, you have to make sure to tell them to make exactly the same changes to their copy of the database. South makes it much simpler, IMO.

That being said, it might be cool if South had an option to delete all previous migrations, so you could start with a clean slate when you're wrapping up the initial dev and starting to add real data. But ultimately those dozen or so extra migration files aren't really costing you anything.

Answer 5

I don't use South during the initial development. I just have a script which creates fixtures for each app, so when the schema changes, I dump the old testing data, edit the schema, update the testing data so that it will work with the new schema, then restore the data.