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


Mime
View raw message