Update database with model changes

[Robert Steckroth]

Hey Gang, is there a way to update the database with a syncdb or
other command after a model has been changed? I added a field
the the model after the syncdb.


--
Bust0ut, Surgemcgee: Systems Engineer ---
PBDefence.com
BudTVNetwork.com
RadioWeedShow.com
"Bringing entertainment to Unix"

[Kevin Anthony]

Use south

Kevin
Please excuse brevity, sent from phone

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Nikhil Verma]

If you mean you added a field after creating a model class table you need to generate the sql statement for the new field only( for hint , django will generate automatically if you do python manage.py sql appname and see the sql) in a file and execute that file .

Let say you have xyz.sql just run that file.The table/database will be updated.
I hope this info might help you !!!!!

--
Regards
Nikhil Verma
+91-958-273-3156

[Psamathos]

South will handle schema migrations for you: http://south.aeracode.org/

This tutorial is a good place to start and covers the basic set-up: http://south.aeracode.org/docs/tutorial/part1.html

Basically, you want to revert your changes so your model matches your database, install south and configure your app to use it, then convert your models to use south by typing:

python manage.py schemamigration [appname] --initial

This creates migration files which are stored in [appname]/migrations/

You can then apply these migrations using this command:

python manage.py migrate [appname]

Note that you need to do this for each app in your project. When you change the model and want to update the database, you can create migration files automatically with:

python manage.py schemamigration [appname] --auto

Then just apply them as you did with the initial migration.

Some best practices for avoiding issues with South:

• If your model has a NOT NULL field then it should always have a default. That way South will know what value to fill in when it creates the field.
  
• If you are changing a pre-existing model field drastically and don't care about losing data, I find it most convenient to remove the field, migrate the schema, then add the field again with the new specification . This way you will avoid conflicts with any existing constraints. Note that to preserve the data you'll need to create a (more complicated) data migration.
  

Hope this helps.

[Robert Steckroth]

Well, that would be a lesson for me.
Looks like I will have to incorporate south into my endeavours.
Much thanks to the Django community.

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/-TIpt70lWX4J.

>
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.