On Thu, Feb 14, 2008 at 11:23:19AM -0800, Philip Brown wrote: > Danek Duvall wrote: > > On Thu, Feb 14, 2008 at 10:30:58AM -0800, Philip Brown wrote: > > > >> It seems like you are limiting your view, to OS level "databases". > >> What about actual "databases", or "database-like" applications that may be > >> packaged, that may benefit from database-specific postinstall type actions? > >> Or, database-USING applications. > >> > >> For example; some web application that uses a database; When upgrading > >> from > >> version 1.0.3, to version 1.0.5, it is required to run > >> "upgrade_from_old_ver.sh", otherwise, the application becomes > >> non-functional, or worse yet, corrupts the data. > > > > It sounds like this is a case where both 1.0.3 and 1.0.5 need to be on the > > system at the same time, so that upgrade_from_old_ver.sh has access to both > > the old bits and the new bits, yes? > > no... that's why I said "upgrade". > The script has access to the old *data*, in the untouched back-end database. > but "version 1.0.3 bits" will not exist any more on the system.
I saw "upgrade" and was responding to it. Perhaps I missed the thrust of your argument. If 1.0.5 can't read 1.0.3 data, and presumably 1.0.3 can't write 1.0.5 data, then what can upgrade_from_old_ver.sh do, either as a preremove script in 1.0.3 or as a postinstall script in 1.0.5 to convert the data from the 1.0.3 format to 1.0.5? As far as I can tell, you've nailed yourself into a corner, but obviously you must be thinking of something else. > > You're right that the Oracle 15.0 package would have a fresh script to > > upgrade all your Oracle 14.x databases correctly, but like I said above, I > > think that's the wrong way of tackling that particular kind of problem. > > well, oracle is a huge horrible complex beast, that always seems to require > more handholding than one might think. > What about things considerably less complex than oracle, though? What do you > think the "best" way of handling that sort of thing is? The best way is always going to be that the software responsible for managing the data is capable of reading old formats for some period of time after it stops writing those formats by default, and either doing an automatic conversion, or allowing the customer to decide when that conversion happens -- should they ever wish to downgrade, or the data is shared between systems that might have different revisions of the database software. See ZFS for one example of where this works quite smoothly. If the data format is sufficiently volatile that it's not cost-effective for the software developer to do this, then the burden is shifted to the end-user, who has to deal with a more complicated upgrade procedure, possibly including hand-holding by the developer. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
