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
behavior.
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.
