Database migration practices?

[xamdam]

I have not found anything in the docs about this (DB migration), and
searching this group yields only two measly irrelevant results (which
freaks me out).

What's the current suggested approach for changing the DB schema with
django? What are the best practices for handling migrations without
loosing data? Did I miss something in the docs?

thank a lot,
max.

[Mason Browne]

I assume here you're referring to the schema alterations associated with the next version of Django?  If that's the case, follow the magical link: http://code.djangoproject.com/wiki/RemovingTheMagic

On 2/19/06, xamdam <maxk...@gmail.com> wrote:

I have not found anything in the docs about this (DB migration), and
searching this group yields only two measly irrelevant results (which
freaks me out).

What's the current suggested approach for changing the DB schema with

--
:: Mason Browne
:: w - 406.208.5956
:: h - 4468

[xamdam]

No, I am talking about altering the DB schema of your app. (I started
off withthe noMagic branch, so there is nothing to migrate)

[Max Battcher]

xamdam wrote:
> No, I am talking about altering the DB schema of your app. (I started
> off withthe noMagic branch, so there is nothing to migrate)

Right now there is no automatic way to do schema migration, as it's a
very serious thing to do (ie, do you want an automatic tool potentially
destroying your data?).

The assumption is that you should be able to come up with the SQL ALTER
statements yourself. Basically, you probably want your db's SQL manual
close at hand and use a development database to test changes on. The
manage.py sql* commands are also your friends to show you what the final
schema should be.

--
--Max Battcher--
http://www.worldmaker.net/

[Ken Kennedy]

I have to concur with Max here. I know it sounds like a pain to migrate
schema changes BY HAND...but trust me, the tools don't help that much.
I'm a DBA in my day job (MS SQL, Oracle, and Postgresql primarily), and
the majority of the problems that occur when developers are trying to
do application migrations are from auto-DDL generation tools. And it
gets to be kind of a big deal when your have a public-facing
application or something...*grin*

That being said, I'm a big fan of automated assistance in this area,
but don't blindly rely on it. A place to start is "what objects are
different" between dev and prod (or ideally, testing. *grin*). Just
that list is helpful, as it'll keep you from missing something obvious.
Start with this list, and it'll make things simpler to deal with w/o
automagically breaking your nice production app!

[Brant Harris]

I plan on making a migration solution after Magic-Removal trunks. I
have a partial-solution now, but I don't want to work on it just to
need to redo everything afterwords.

[Tim Keating]

The way I typically do this is:

1. Rename the schema.
2. Update my model files.
3. Re-run django-admin install install myapp.
4. Write SQL statements to migrate the data from the renamed schema to
the newly-regenerated schema.

This sounds riskier than it is, but my experience has been that as long
as your DB does the right thing with auto fields, it's fine.

TK