db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [PATCH] upgrade fix related to checksum support for transaction log to recognize out of order log writes during recovery (Derby-96)
Date Fri, 22 Apr 2005 18:32:39 GMT
Ok, that is the info I needed.  Suresh could you resubmit the change
with comments like the one dan has below.  And change the check to
simply check if the on disk version is is 10.0, no need to check
current version.

It would be nice to have some sort of store facility like the one
language has, but the problem for this case is that logging system
needs it during boot and there is not much else available until boot
is finished.

Daniel John Debrunner wrote:
> Mike Matrigali wrote:
>>Given that Dan is working on the upgrade stuff, I think the change below
>>handles the current, and next release fine.  More changes can be made
>>as it becomes clear how rest of code is handling soft upgrade.
>>Going forward I would like to see a better model for the code below. For
>>this discussion assume current release is 10.0.x and next 2 releases
>>are 10.1.x and 10.2.x.  If derby supports soft upgrade from 10.0.x
>>directly to 10.2.x then the code below will have to change, meaning
>>someone is going to have to remember to change it (maybe a sanity
>>statement could force an error if version is not what is expected?):
> Soft upgrade is expected to work on any previous release, and the code
> to handle it should work without having to change every release.
> Take a language feature that was added in release X and cannot be used
> in soft upgrade mode because it writes new information to the system
> catalogs, that would not be understood by releases earlier than X.
> The language layer handles this by checking that the database (on disk)
> has been upgraded to at least release X before allowing compilation or
> execution of the feature, by calling the method
> DataDictionary.checkVersion().
> E.g. for a routine with a method signature (new in 10.1) this check is
> made (I'm just about to commit this code).
> // Support for Java signatures in Derby was added in 10.1
> // Check to see the catalogs have been upgraded to 10.1 before
> // accepting such a method name for a routine. Otherwise
> // a routine that works in 10.1 soft upgrade mode would
> // exist when running 10.0 but not resolve to anything.
> if (this.methodName.indexOf('(') != -1)
> {
>   getDataDictionary().checkVersion(
>      DataDictionary.DD_VERSION_DERBY_10_1,
>                "EXTERNAL NAME 'class.method(<signature>)'");
> }
> This style of check will work with any future version so it's a safe
> approach.
> The store layer needs to have a similar policy.
> Dan.

View raw message