Thanks for the clarification, Dan. So it appears that Hard and Soft
Upgrade are two independent axes of change. Transforms along these axes
obey the following rules:
o Transitive
o Idempotent
o NOT Invertible
It appears that changes to the database are partitioned into two
buckets: those accomplished by Hard Upgrade and those accomplished by
Soft Upgrade. Examples of Soft Upgrade changes appear under item (2)
under the heading "Upgrading System Catalogs" on the webpage
http://db.apache.org/derby/papers/versionupgrade.html#Version+Upgrade+Mechanism.
These are useful examples. Do we have a process for guaranteeing that
future database changes end up in the right bucket?
Thanks,
-Rick
Daniel John Debrunner wrote:
Discussion moved to derby-dev
Rick Hillegas wrote:
Soft Upgrade is a feature which I think was introduced after I left
Cloudscape. Please bear with me as I try to understand how Soft and Hard
Upgrade interact.
In the old days, when there was only Hard Upgrade, Upgrade satisfied the
following contract:
o Transitive - You could upgrade data from a lower version to any higher
version by applying all of the intervening transforms in sequence.
o Idempotent - Applying the same transform a second time was a nop.
The version numbers themselves were organized in a tidy, ascending
sequence. This determined the order in which the Upgrade transforms
composed. So, for instance, you had versions h1, h2, h3, h4 with
corresponding transforms H2, H3, H4 and you could expect that h4 = H4(
H3( H2( h1 ) ) ).
With Soft Upgrade, it appears that there is a second set of version
numbers s1, s2, s3, s4 and a second set of corresponding transforms S2,
S3, S4 and I would expect that s4 = S4( S3( S2( s1 ) ) ).
But the situation might be more complicated than this. A database is now
tagged with both a Hard and a Soft version number so that the database
version is really an ordered pair ( hn, sm ) where m >= n. That is,
version numbers are no longer a tidy, ascending sequence. Instead, the
space of possible versions is a grid of points bounded by a triangular
shape.
What I am struggling to understand is how one upgrades from version (
h1, s3 ) to ( h2, s? ). How does the H2 transform know what to do with
the result of the S3 transform, given that S3 was coded after H2 shipped?
hm and sn are two indepdendent upgrade streams. Thus in your case you
would upgrading {h1, s3 ) to {h2, s3}. The upgrade code would see that
the soft upgrade is at a version greater than the engine is at (s2) and
so not apply any "safe" changes.
Soft upgrade typically will not make changes, we had one case prior to
open sourcing where upgrade could fix a bug in the system catalogs that
was causing a failure elsewhere. Any change by soft upgrade has to be a
fix that can be safely consumed by older versions of the engine, down to
the level of the database.
Currently there are no actions in soft upgrade, they are made in the
DD_version.applySoftChanges method which contains no actions. The
javadoc for that method tries to explain what it could do.
Dan.
