db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Soft Upgrade and Downgrade
Date Wed, 22 Mar 2006 23:14:17 GMT
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.

This was the conclusion I was happy to come to yesterday after Dan 
answered my questions in the related thread titled "Hard vs. Soft 
Upgrade": Soft Upgrade should be a misnomer, and "No Upgrade" should 
describe the situation better.

Today, however, I was taught the following curious fact about 
DatabaseMetaData methods:

o When the customer calls one of these methods, it causes the server to 
fault in some query text from the server jar files, to compile that 
query text, and to store the compiled form in the database. From that 
point onward, the compiled form is locked in place and determines the 
results of the DatabaseMetaData method for all subsequent callers.

o The results from a DatabaseMetaData call therefore depend on whether 
the first user faulted in the text BEFORE or AFTER the Upgrade. It seems 
that this indeterminate behavior is induced by Soft Upgrade and maybe by 
Hard Upgrade as well.

Is this true? What other wormholes lurk in Soft Upgrade? I would think 
that anyone who has to support Derby would be happier with deterministic 

> 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.
Upgrade is clearly an operation which stretches the "0-admin" claim a 
bit past the cracking point.

View raw message