This seems a lot like what was supposed to happen in the SoC solution
(at least according to what was posted on the Wiki).
Derek seemed to do a very good job with the analysis and writing of
functional specs, but I think Victor Ng's approach is slightly
different.
Honestly, I haven't had time to look really closely at either, but I
will try to before school starts up again in a week and two days. And
then I'll be slammed until June.
Todd
On Sun, 2006-12-24 at 08:55 -0500, Ned Batchelder wrote:
This is the method I've used in a few projects, and am now using with
Django in Tabblo:
1) You add a sequentially-increasing number called the schema number to
your code. Any time the models change in a way that changes the db
schema, this number is incremented.
2) A table is added to the database which records the current schema
number in the database. My table has a record for each schema the
database has migrated through, rather than just a single record for the
current schema, because it provides historic and forensic information,
and is going to be tiny anyway.
3) When changing the model, the developer must also write a Python
evolution function which applies a delta SQL to update the database
schema. This function is named in such a way that the introspection in
step 4 can find it automatically.
4) At server startup, the number in the code is compared to the current
number in the database. If they are different, evolution functions are
found via introspection and executed to update the database.
5) Once the database has been fully evolved, there is a verification
step: a test database is created, and populated directly from the models
with Django's django.core.management functions. Then the test database
and the production database are compared to see if they have the same
schema.
This method has these advantages:
a) Evolution is applied automatically. You can have a development team
of any size, each developer with his own dev database, and they will all
be upgraded without any attention or coordination by the developer.
b) Evolution can involve much more than simple add/drop/alter tables and
columns. If you decide to change your FirstName/LastName columns into a
single FullName column, the evolution code can do the work to transform
the data so that when the evolution is done, all of the data is
correct. We've had evolution steps that didn't change the schema at
all, merely changed or corrected records in the database.
It also has these disadvantages:
a) The developer has to write two pieces of code when changing models:
the model itself, and the evolution function. In practice, this is
somewhat routine, and has not been a burden, and the verifcation in step
5 double-checks that the evolution function and the model change
correspond properly.
b) It gets very complicated to manage this process when branches are
involved, if there will be evolutions on more than one branch at the
same time. But I don't know how to simply manage that complexity in any
solution.
I also wrote a little about it here:
http://www.nedbatchelder.com/blog/200512.html#e20051218T105947
--Ned.
http://nedbatchelder.com
Aaron Jacobs wrote:
>
> On 12/23/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>> 2. if you are not worried about data loss run sqlreset - or better,
>> drop the database, create it and run syncdb
>> 3. if you alter a model, run sqlall, examine the out put to see what
>> statements django wants and put them in manually
>
> These two are fine for a single developer's purposes, but what about
> if you want to distribute your app to others? You'd have to come up
> with some automated process, even if it's hand-coded.
>
> I really hope Django gets a migration feature like RoR's sometime soon.
>
> >
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
