db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Hard vs. Soft Upgrade
Date Wed, 22 Mar 2006 01:05:05 GMT
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.


View raw message