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: Hard vs. Soft Upgrade
Date Thu, 23 Mar 2006 01:04:29 GMT
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 
These are useful examples. Do we have a process for guaranteeing that 
future database changes end up in the right bucket?


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