I think a better aproach will be to save a .back of the model, make the equivalent of a diff and then generate a little script that will do what your "up" and "down" methods do.
Which by the way is flawless since there is no human involve that can make a typo.
Also I'm not sure if an SQLObject will be able to accept all the transformations and still trusted, db relations are hard to maintain with many alter tables and most of the time a clean .sql is the best way to go.
I still think that this feature is not that great since in dev env stored data is irrelevant, and drop,create,populate should be encourage. And in production most people wont trust their data to a thirdparty system.
-1 from me
On 3/14/06, Justin Johnson <[EMAIL PROTECTED]> wrote:
I've configured my setup so that I can specify a 'rebuild' command line
option when running my app. If specified, it drops the tables,
recreates them and then loads them up with test data.
This is only a very short term solution though.
Ideally what's required is a TurboGears equivilent of a tool like RoR's
ActiveRecord::Migration
(http://api.rubyonrails.com/classes/ActiveRecord/Migration.html )
I'll see if I can explain how this technique might work for us:
This is a very simple feature that provides the ability to migrate
models either forward or backwards in history.
The basic idea is to have a migrator class that supports up() and down()
methods that advance the database scheme forwards or backwards.
class AddAddress(Migrator):
def up(self):
MyTable.addColumn("address", length=20)
def down(self):
MyTable.delColumn("address")
This can be stored in a migrations source file, say, 001_AddAddress.py
in a migrations folder. The '001' denotes a version of the database
scheme. Examples:
001_AddAddress.py
002_AddTags.py
003_RemoveMemberShip.py
...
Providing you know which version of the schema you're on, it's possible
to move backwards or forwards through history by calling up() or down()
until you get to the required version. For example:
tg-admin sql migrate 002
will update the database by calling up() or down() in the version stack
until you get to 002_AddTags.py
It's possible to fill the up() and down() methods with any code you need
to facilitate the migration.
It's almost possible to add this facility using SQLObject. It has the
add and delete column facilities but is missing some features. We need
features to remove indexes, rename columns.
This could be a really nice addition to SQLObject.
Justin
> Hey guys
>
> I'm using .9a1 and I keep modifying my model, which leads to major
> headaches because the only way I know to get the proper table structure
> is to tg-admin sql drop; tg-admin sql create - and this means I lose all
> my data! Can anyone provide any suggestions on what to do about this?
>
> Thanks
>
> -Rob
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
