Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42692D1D.3030306@debrunners.com>
Date: Fri, 22 Apr 2005 09:58:05 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [PATCH] upgrade fix  related to checksum support for transaction
 log to recognize out of order log writes during recovery (Derby-96)
References: <42669D4F.7000007@gmail.com> <4268394C.2090201@sbcglobal.net>
In-Reply-To: <4268394C.2090201@sbcglobal.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.