0

On my local development screen I'm using South data migration. I deploy my apps to using git to my production server. I have placed all /south/ folder into my git .ignore file. However, south is still listed in my installed apps.

My question is. Should I include south on the production server also, or just split my setting files out local and production with south only install on local.

How do others handle this?

Thanks

Prometheus
  • 32,405
  • 54
  • 166
  • 302

2 Answers2

2

I see no reasons to not install/use south in your production server, it will provide you a way to alter the db schema also in production server in the future. I usually do that and I manage both development and production schema migrations using fabric.

Splitting settings file may be required anyhow (e.g. for DB/Debug settings)

You may also conditionally add south to INSTALLED_APPS basing on something in your settings.py:

e.g.

if DEBUG:  // or hostname == 'localhost', path=='...', anything else
    INSTALLED_APPS += ('south',)
furins
  • 4,979
  • 1
  • 39
  • 57
  • just out of curiosity what reason would you have to install or use south in the production environment? – Prometheus Jan 25 '13 at 15:05
  • I believe south is needed in production, because otherwise your `migrate` command won't run. – styts Jan 25 '13 at 15:10
  • if my customer ask me a quick change in the db schema: I change the model in django development server, run schemamigration, test it, then if everything is ok with just a fabric command I commit changes, do a checkout on production server, run a manage.py migrate , restart the webserver. Otherwise I have to change the DB schema manually, it may be tedious if the changes are complex (this is the reason south exists, I think) – furins Jan 25 '13 at 15:10
  • @Spike otherwise you have to do something like http://stackoverflow.com/questions/5739880/django-update-database-schema-without-loosing-data – furins Jan 25 '13 at 15:16
  • @furins sorry if I'm asking silly questions, trying to get my head around South. If i run manage.py migrate on my development server this would so the same as running on my production tho, right? therefore I only need to sync db once and this 'could' be done from development without having to use south on the production. is this correct? i.e. my development machine is connected to the live db. – Prometheus Jan 25 '13 at 15:18
  • @Spike If you do that, you could easily migrate your live database to the wrong version of the schema. – Steve Mayne Jan 25 '13 at 16:01
  • 2
    @Spike Now I understand why you didn't get the need to install south on production server: you are connecting both dev and prod code to the same database! I have to agree with Steve Mayne: it's not a good habit to connect both development and production code to the same database for many reasons, one of these is it does not allow you to "experiment" different solutions during development before going to production. And, btw, you don't have to apologize, we are all here to learn from each other! – furins Jan 25 '13 at 17:16
  • +1 on not connecting dev code to prod db.. it is EXTREMELY bad practise. I was doing this for years, it is dangerous, it does not scale, and prevents you from building applications "the right way". – SleepyCal Jan 14 '14 at 19:44
1

I personally use south on my production server. This allows me to run data migrations on the live db using the normal manage.py migrate command. This ensures that the live db is migrated to the correct point for the deployed version of the code.

Steve Mayne
  • 22,285
  • 4
  • 49
  • 49