4 ms·

I'd say don't worry about south if you're not working with a big team. Just track the changes you make to your models and make the same changes to the databas

I'd say don't worry about south if you're not working with a big team. Just track the changes you make to your models and make the same changes to the database.

gardarh 13y ago
I don't agree with that. I'd say don't worry about south if you're just starting out playing with django and willing to manually delete tables every now and then to get make sure your db matches your models. As soon as you are doing something that anyone relies on and to save you endless effort you should use South, IMO. Even if it's a one-person project (I have a few of those) South saves you both a lot of time and aggravation.
- frankwiles 13y ago
  Absolutely agree. Even something as simple as adding an optional field is just ./manage.py schemamigration --auto <appname> and you're done vs "ALTER TABLE blah blah blah...." on your local system, dev/staging, and then again on production in the right order, every time, manually. Can't imagine anyone wanting to go back to manual after using South.
  - rmrfrmrf 13y ago
    This thread perfectly exemplifies the frustration laid out in my original post.
    - jaegerpicker 13y ago
      Welcome to development with open source technology. It takes time and effort to figure out the best practices. There is no magic bullet, sorry. That's not meant to be snarky it's just the way the process works.
  - collyw 13y ago
    And use Postgres as the database. If you use MySQL you will get sick of South telling you to use Postgres whenever a migration doesn´t go smoothly.
mildtrepidation 13y ago
Definitely not good advice, regardless of what language or framework you're working with. If there's a solid migration tool available, it is definitely better to use it. Aside from being a great habit to get into, South (or whatever other migration tool you want to use) will keep your database consistent and predictable to the framework. If you add or alter columns on your own, you run the risk of slight differences between what you've done and what the framework would've done left to its own devices. You may not have done anything wrong, but you don't want that inconsistency.
r0muald 13y ago
Migrations are going to be a core feature (quite similar to Ruby on Rails) from Django 1.7, and I personally find it more convenient. Eventually you will need to use migrations anyway.
metaphorm 13y ago
I honestly find South to be the easiest and most efficient way to make model changes even on a solo project. The biggest upside to it is that it fully documents all of your chances, and even allows rollbacks if necessary. Editing the database directly doesn't give you any kind of change log unless you do it manually, which is not really sustainable, even while working solo.

I'd say don't worry about south if you're not working with a big team. Just track the changes you make to your models and make the same changes to the database.

gardarh 13y ago

I don't agree with that. I'd say don't worry about south if you're just starting out playing with django and willing to manually delete tables every now and then to get make sure your db matches your models. As soon as you are doing something that anyone relies on and to save you endless effort you should use South, IMO. Even if it's a one-person project (I have a few of those) South saves you both a lot of time and aggravation.

frankwiles 13y ago
Absolutely agree. Even something as simple as adding an optional field is just ./manage.py schemamigration --auto <appname> and you're done vs "ALTER TABLE blah blah blah...." on your local system, dev/staging, and then again on production in the right order, every time, manually. Can't imagine anyone wanting to go back to manual after using South.
- rmrfrmrf 13y ago
  This thread perfectly exemplifies the frustration laid out in my original post.
  - jaegerpicker 13y ago
    Welcome to development with open source technology. It takes time and effort to figure out the best practices. There is no magic bullet, sorry. That's not meant to be snarky it's just the way the process works.
- collyw 13y ago
  And use Postgres as the database. If you use MySQL you will get sick of South telling you to use Postgres whenever a migration doesn´t go smoothly.

mildtrepidation 13y ago

Definitely not good advice, regardless of what language or framework you're working with. If there's a solid migration tool available, it is definitely better to use it. Aside from being a great habit to get into, South (or whatever other migration tool you want to use) will keep your database consistent and predictable to the framework. If you add or alter columns on your own, you run the risk of slight differences between what you've done and what the framework would've done left to its own devices. You may not have done anything wrong, but you don't want that inconsistency.

r0muald 13y ago

Migrations are going to be a core feature (quite similar to Ruby on Rails) from Django 1.7, and I personally find it more convenient. Eventually you will need to use migrations anyway.

metaphorm 13y ago

I honestly find South to be the easiest and most efficient way to make model changes even on a solo project. The biggest upside to it is that it fully documents all of your chances, and even allows rollbacks if necessary. Editing the database directly doesn't give you any kind of change log unless you do it manually, which is not really sustainable, even while working solo.