Good points... Also, if Derby is being embedded in other applications that provide reverting back to older versions, wouldn't automatic upgrade of Derby prevent embedded application from reverting? I do think soft-upgrade is a very useful feature to have, especially for embedded databases.
Satheesh Mike Matrigali wrote: > The way I look at it, derby has a very nice default. We call it soft > upgrade, but in my mind it really is "no upgrade". We guarantee that > if you do nothing to your existing app, then you can run it and the > database against your current version of the derby software and all > future versions of the derby software. I think this is a reasonable > "automatic" default. > > Because we provide no way to "go back" with database versions I believe > it is reasonable to require the very slight user intervention of > connecting and requiring the upgrade=true flag. If you want to use new > stuff then you proactively tell us. This model is really important if > we ever decide to do some sort of major data upgrade where the cost > of hard upgrade may be hours depending on the size of the db and number > of rows touched. > > Oystein Grovlen - Sun Norway wrote: > >> I agree that soft upgrade has a value, but I think you give soft >> upgrade credit for things that are actual not provided by soft >> upgrade. More comments below. >> >> Kathey Marsden wrote: >> >>> Rick Hillegas wrote: >>> >>>> 4) What is the customer problem solved by Soft Upgrade? >>> >>> >>> >>> >>> Soft upgrade solves many problems for users , support and >>> development. It: >>> >>> - Minimizes end user intervention in accordance with Derby's charter >>> http://db.apache.org/derby/derby_charter.html. >>> which calls for ease of use and zero administration for end users. >> >> >> >> It is not soft upgrade that minimizes end user intervention. That is >> provided by automatic upgrade (soft or hard). In fact, soft upgrade >> increases user intervention since you will need to explicitly state >> that you want to do a hard upgrade. Without soft upgrade, hard >> upgrades could have been done automatically. >> >>> - Encourages upgrade and reduces the need to port fixes to old >>> releases. >> >> >> >> I agree that people will probably be less hesistant to upgrade to new >> releases if they are able to revert to their old release. In my >> opinion, that is the only value of soft upgrade. In itself, I would >> not think that using the old data format should make it much less >> risky to upgrade than using a new data format. And if I had to >> downgrade due to problems with the new release, how do I know that >> this new faulty release has not corrupted my database? >> >>> - Provides applications, embedding or including Derby a scalable >>> deployment option for distributing new versions of Derby. >> >> >> >> How is soft upgrade provide more scalable deployment than hard upgrade? >> > > >
