South and syncdb
I didn't understand why we used south to change our db instead of running syncdb, could you please explain me?
Answers
The reason you have to use South is because syncdb is stupid. All syncdb checks for is the existence of the table, not the contents of it. So if you change your model, add an index or uniqueness constraint, or anything else, syncdb basically says "Yep, that table exists" and happily goes on its way.
South, on the other hand, compares what's basically a diff between the table as it is in the db and how it is in the models file, and then figures out what it needs to change.
kennethlove (Staff)
on
kennethlove (Staff)
on
jollyfellow
on
I can give you a fellow beginner's take on this since I have had the same question. And one day I tried to add a field with unique=True to an existing model. As it was time to grew out of dropdb/createdb childishness I just did it the hard way. South comes to a rescue because you can just write instructions populating new fields.
In my example I wanted to create a meta_title field. It doesn't really need to be unique but I wanted it to. This is how it looks in a migration file:
def forwards(self, orm):
for post in orm.Post.objects.all():
if not post.meta_title:
post.meta_title = post.title + " | Hardcoded Site Title"
post.save()
It made my meta_title fields populated in this manner: "Blogpost about butterflies | Site Title"
Just use South, it's a must have. You will get to this point yourself, believe me :)
Jiloc
on
kennethlove (Staff)
on