db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Hard vs. Soft Upgrade
Date Wed, 22 Mar 2006 00:23:21 GMT
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?

I'm puzzled about how one upgrades along two axes.

Thanks for helping me muddle through this,
-Rick

Mime
View raw message