db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Hard vs. Soft Upgrade
Date Thu, 23 Mar 2006 22:34:03 GMT
Rick Hillegas wrote:

> Daniel John Debrunner wrote:
>> Deepa Remesh wrote:
>>> On 3/22/06, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>>>> 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.
>>> I was looking at this document and it is not very clear to me what can
>>> be categorized as "safe changes" as mentioned in this statement:
>>> "Apply "safe changes" from category 2) in a single transaction. An
>>> example would be fixing incorrect information. ".   
>> Does this help (javadoc for DD_Version.applySafeChanges)?
>> http://db.apache.org/derby/javadoc/engine/org/apache/derby/impl/sql/catalog/DD_Version.html#applySafeChanges(org.apache.derby.iapi.store.access.TransactionController,%20int,%20int)
> It's nice to see this documented, but it's not clearing up my confusion.
> The definition given here implies that a change is "safe" as long as you
> can reboot the database using old versions of Derby. What if, many hours
> after booting the old Derby version, a method returns odd results or the
> server actually crashes?

Sounds like a bug to me. Of course there's a risk that running *any* new
software could corrupt the database for the old engine, but the
intention is that soft upgrade allows one to revert versions.

> So far I have seen only two examples of "safe" changes
> o changing the nullability of a system column

Yes. The old engine can understand a column being nullable or not
nullable. This change is consumable by older versions.

> o changing the value in a set of rows to support new functionality (I'm
> a bit unclear on what this means, a concrete example would help)

That was not meant to be an example of a safe change.

The example for this (non-safe change) is say I implement some
functionality with two modes today and use the values 'A' and 'B' in a
system column to represent the two modes 'Orange' (A) and 'Bananna' (B).

Then in a different future release I add three new modes to the same
functionality, 'Apple', 'Pear' and 'Cherry'. I have two options:

1) leave the existing letters alone, and use Apple (R), Pear (P) and
Cherry (C), with Orange (A) and Bananna (B)

2) Decide that it would be less confusing if I used Apple (A), Pear (P)
and Cherry (C), with Orange (O) and Bananna (B). So I write upgrade code
that changes all the existing 'A's (Orange) to 'O'.

This type of change is not consumable by the older versions since they
are expecting the mode to be A or B, and have no code to handle O.

> It's hard for me to generalize from these two examples. Maybe the answer
> is:
> o We can't spell out the rules yet because we haven't played with this
> scheme long enough.

I think the rules are simple, I'm a little lost as to where the
confusion is coming in. Simply put, don't modify the database in such a
way that a previous version of the engine could not consume it.

> o Over several releases, we will collect more examples and distill a
> definition based on a case-by-case study of every upgrade-induced
> database change we introduce

Examples will help.


View raw message