17

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?

adewinter
  • 193
  • 1
  • 8
  • I agree. This is why I think Django needs some integrated schema changing functionality in the core because it's very frustrating as it is currently. – meder omuraliev Feb 16 '11 at 21:02
  • @meder how do you propose doing that without a migration system? In my mind, south fills the gap just fine. – Kekoa Feb 16 '11 at 23:28
  • I just keep a version controlled file evolve.sql pasting in SQL command after every model change that affects the database. I also have an evolve.py which uses lower level DB wrapper (MySQLdb in my case) for data intensive migration changes. Less code, less things to go wrong. I wouldn't want things to go wrong, when it comes to data. – fmalina Feb 17 '11 at 00:07
  • @Frank that may work for schema changes(provided you keep track of which commands have been previously run). With south, you don't have to write SQL(it's more portable, and who wants to write SQL anyway?) to make the changes. Also your solution is nightmare-ish if you have multiple developers on the same project. – Kekoa Feb 17 '11 at 16:58
  • There's nothing nightmare-ish about that. The only scary thing to me is just another dependency. Portable migrations code is the last thing I would useful. Automation provided by frameworks makes people lazy. There's is nothing wrong about writing your migration SQL in the dialect specific for your database, unless you make a product for programmers and you have to support different databases. Learn your database early, so you don't need to pull your hair out when it grows. Low level is good. When it comes to data consistency, you want to know what EXACTLY is going on. – fmalina Feb 17 '11 at 20:52

5 Answers5

16

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.

Kekoa
  • 27,892
  • 14
  • 72
  • 91
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.

danny
  • 10,103
  • 10
  • 50
  • 57
  • Regarding deleting all previous migrations, if you want to start fresh from your current schema(mimicking syncdb), you can simply drop all tables in your database and remove all migrations, then do a schemamigration --initial for each app. – Kekoa Apr 20 '11 at 03:31
2

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.

David Wolever
  • 148,955
  • 89
  • 346
  • 502
0

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.

Alveoli
  • 1,202
  • 17
  • 29
0

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.

marue
  • 5,588
  • 7
  • 37
  • 65