MikeH wrote:
> Hi all,
>
> I'm currently preparing my team to use Django as our primary framework
> and as part of this we need a way to keep our databases in sync.
>
>>From the Django FAQ:
>> you'll have to execute the ALTER TABLE statements manually in your database.
>> That's the way we've always done it, because dealing with data is a very
>> sensitive
>> operation that we've wanted to avoid automating. That said, there's some work
>> being done to add partially automated database-upgrade functionality.
>
> I agree completely with this, and our developers write sql scripts to
> migrate the database to the new structure, test the migration and
> commit it so that everyone else can bring their schema up to date. The
> problem is keeping track of what has been run on where and remembering
> to run the right sql so that your application doesnt crash with an
> OperationalError. We needed the process to be as easy to run and as
> automated as syncdb.
>
> We looked at the schema-migration branches but they dont seem to be as
> current or complete as we need.
>
> So I wrote a very simple schema migration tool which you can find at
> http://www.aswmc.com/dbmigration/
>
> It simply automates the application of migrations, written in SQL
> (allowing you to supply a default bt of sql or an engine specific
> version) or as Python functions, and keeps track of the ones that have
> been applied to the schema so they don't get run again.
>
> There is a patch to integrate it into syncdb, so now the stage of our
> rollout that updates the database is as simple as running syncdb! I
> posted the package to the django-users list and have had positive
> feedback from various users there.
>
> I'd really like to see something like this supplied with django so
> that we don't have to resort to external scripts or bits of other
> frameworks to automate our schema migrations.
>
> Cheers,
>
> Mike H
>
>
> >
Interesting solution. So, to handle the "keeping track of what [schema
alteration] has been run on where" use case, developers would just edit
migration_list before running the migrations? I'm trying to get an idea
of how I would use this with my team.
I presume, if developer A had already applied the first couple
migrations to their testdb, they'd do something like:
migration_list = [
# 'migration1',
# 'migration2',
'migration3',
'migration4',
]
before running it. Is that how you use it?
John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
