On 3/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
It still seems like 2 versioning systems
I never said diff (as in the program), I said equivalent of, as in make it automatic as oposed to have to write it.
This has always been a problem with web, since there is no such thing as "versions" or "releases"
True but it could get you to a point where there is no way to redeploy your project as a single package (like a version and a bunch of patches).
You don't have to take it offline, all you need is a replica, eventually you will have so many patches that it will be better to redeploy, at which point you may not have a "full copy"
Yes your totally right this is something for SQLObject to handle not TG
> how will you control that your controllers are in 005 but your db is in 004?
> I think a better aproach will be to have SVN or sometimes else, appliying
> this to all the project tg will be like building a versioning system on top
> of it which makes no sense.
Your latest migration will be in-sync with your controllers. If you're SVN versioned from there backwards everything will work.
It still seems like 2 versioning systems
> 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.
The idea behind the up() and down() methods is that you have total control over how the model upgrades/downgrades. You may want to fill-in default fields, throw an exception if you don't allow downgrading, adjust other table content when a downgrade/upgrade happens and so on. You can put whatever operations you need to in there to make it work.
OTOH, diff is flawed - it can't handle some common cases. It won't be able to handle renames properly and won't be able to do any custom adjustments as outlined above that you'll probably need in real world scenarios. You won't get very far with it.
Textual diffing two SQLObject models is not going to provide a reliable upgrade path from one model version to the other in all but the simplest cases.
I never said diff (as in the program), I said equivalent of, as in make it automatic as oposed to have to write it.
> 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.
Yes, the easiest way is to alter your model and then rebuild/repopulate. If you can do that early on in dev then that's cool - I'm doing it now.
But it's very likely that when you go live you'll still be developing. Having to rebuild/repopulate is going to kill your iteration cycle and becomes a bad idea as your data grows. What you need is a way to upgrade _incrementally_ if you can.
This has always been a problem with web, since there is no such thing as "versions" or "releases"
At least with this system your production model upgrade is helped by you being able to write a migration, unittest it and then deploy incrementally when the time is right.
True but it could get you to a point where there is no way to redeploy your project as a single package (like a version and a bunch of patches).
The alternatives are taking it offline and doing a recreate/repopulate or manually typing the SQL to do the migration/transformation by hand. The former isn't practical and the latter could do with formalization which is what this migration technique equates to.
You don't have to take it offline, all you need is a replica, eventually you will have so many patches that it will be better to redeploy, at which point you may not have a "full copy"
Anyhow, I'd have probably written this by now if it wasn't for some missing features in SQLObject.
Yes your totally right this is something for SQLObject to handle not TG
Justin
>
> From: "Jorge Vargas" <[EMAIL PROTECTED]>
> Date: 2006/03/15 Wed AM 01:59:08 GMT
> To: [email protected]
> Subject: [TurboGears] Re: Best way to modify my model?
>
> how will you control that your controllers are in 005 but your db is in 004?
> I think a better aproach will be to have SVN or sometimes else, appliying
> this to all the project tg will be like building a versioning system on top
> of it which makes no sense.
>
> 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
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
- [TurboGears] Re: Best way to modify my model? Jorge Vargas
- [TurboGears] Re: Best way to modify my model? Carlos Ribeiro
- [TurboGears] Re: Best way to modify my model? Jorge Godoy
