Re: DB_VERSION redux

Hi David,

David Nebauer writes:
 > > An entirely different solution is to let refdbd handle the upgrades
 > > internally. refdbd would have to retain the ability to read old-style
 > > databases, save the data to temporary tables, alter the database
 > > schema, and write the data back into place.
 > 
 > Sounds like a brilliant idea and it gets my vote.
 > 

Before I go into the details, I've got one question. Does the package
postinstall script have access to the database admin username and
password?

I don't see a chance to let refdbd handle upgrades silently. To this
end you'd have to make sure the first connection after upgrading is
from the database admin account. This would be easy if the clients
were around - the postinstall script could send a ping to trigger the
upgrade. But as we've seen before it is not an option to rely on the
clients (at least not a *desirable* option).

What I could do is add a command-line switch to refdbd that lets it
run as sort of a one-time version checker. But I'd have to provide the
database superuser name and password to be able to upgrade the
database.

regards,
Markus

-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642