Re: Managing structural DB changes
Mike Schrag <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.devel |
|---|---|
| Message-ID | <[email protected]> |
If you use Project Wonder, definitely look at the er.extensions.migration system ... It's based on this original stepwise article with LOTS of bells and whistles added (framework dependencies, (for very common changes) a SQL-less migration API, etc). ms On Nov 14, 2007, at 6:01 AM, Johann Werner wrote: > Hi Markus, > > have a look at http://www.stepwise.com/Articles/2005/DBChanges/index.html > for a database updater. For each db version you use with your > different app versions you have an incremental change class. So you > have classes that update V2->V2.1, V2.1->V2.2, ... > When your app launches it will look in a special table that it > creates in your database on which version it is and updates it to > the last version it has update classes for. > > jw > > Am 14.11.2007 um 11:43 schrieb Markus Ruggiero: > >> This may be OT in direct relation to WO but certainly not in >> relation to deployment of large scale db apps. >> >> I am sure some (all?) of you have or will have at one point in time >> the following problem: >> >> You deploy your version 1.0 application at a customer site with a >> certain database structure. Now you continue developing your app >> and soon the greatest new version 2.0 will be available. However >> the database structure has changed and you face the problem that >> you have to upgrade the database at the customers site. A simple >> export / drop tables / create tables / import is not doable because >> you may have to split or join tables, move attributes to different >> tables, and make incompatible changes to data types. >> >> How do you manage such a scenario? In my case the application >> manages third party devices (phones). Now every couple of months >> the vendors update those devices or throw completely new ones with >> new capabilities on the market. Our customers expect our >> application to support those new phones and the new or changed >> features. As we are managing different phones from different >> vendors in a unified way we have to update our datamodel all the >> time. As this is an app for the corporate high end market we have >> customers with different releases. Sometimes we have to upgrade a >> customer from V2 to V3, sometimes it is V2.1 to V2.2 or V2.8 to >> V3.4. This means that upgrades are incremental but the necessary >> increments may change from installation to installation >> >> Any and all inputs very welcome >> Thanks and have a nice day >> >> ---markus--- >> >> Markus Ruggiero >> rucotec consulting and technologies email mailto:[email protected] >> rucotec GmbH web http:// >> www.rucotec.ch >> Steinentorstrasse 8 >> 4051 Basel Mobile +41 (0)79 508 4701 >> Switzerland Phone/Fax +41 (0)61 271 4990 >> >> >> _______________________________________________ >> WebObjects-dev mailing list >> [email protected] >> http://www.omnigroup.com/mailman/listinfo/webobjects-dev > > _______________________________________________ > WebObjects-dev mailing list > [email protected] > http://www.omnigroup.com/mailman/listinfo/webobjects-dev _______________________________________________ WebObjects-dev mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/webobjects-dev