db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: Soft Upgrade question
Date Fri, 17 Mar 2006 01:33:53 GMT

Daniel John Debrunner wrote:
> Satheesh Bandaram wrote:
> 
> 
>>
>>Deepa Remesh wrote:
>>
>>
>>>On 3/16/06, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>>> 
>>>
>>>
>>>>When I run a 10.2 server (built from the mainline) and try to connect to
>>>>a 10.1 database, I get the following error:
>>>>
>>>>ERROR XJ040: Failed to start database 'testdb10.1', see the next
>>>>exception for details.
>>>>ERROR XCW00: Unsupported upgrade from '10.1' to '10.2 beta'.
>>>>
>>>>Does this mean that soft upgrade is not working?
>>>>
>>>>   
>>>>
>>
>>I find current behavior inconvinient... I am trying to understand why
>>Derby doesn't allow soft-upgrade from previous releases. I have several
>>customers who are waiting to try some of the fixes/improvements we have
>>been making in 10.2 ALPHA, but the only way they can try 10.2 Alpha is
>>by recreating their current database schema and export/importing data
>>for every table into 10.2. I see several advantages to allow
>>soft-upgrade only, even to Alpha and Beta releases...
>>
>>   1. Increases changes of community testing new 10.2 Alpha release
>>      before it becomes GA. We would like to find issues before Alpha
>>      release goes GA, but users may find it inconvinient to test Alpha
>>      or Beta releases and may choose to wait for GA, unless they really
>>      have to.
>>   2. Not sure what happens when Derby release is marked *BETA *from
>>      *ALPHA*. Would that prevent 10.2 Alpha databases from trying Beta
>>      software?
>>   3. Soft-upgrade is a great model catch regressions in existing
>>      functionality early.
>>
>>I can see why Derby doesn't support full upgrade in ALPHA mode...
>>Catalog changes or information saved in catalogs may not be finalized
>>during development and allowing full upgrade would be hard to support
>>many intermediate versions of catalogs. For example, Grant & Revoke work
>>has been adding catalog changes in batches without having to support
>>many intermediate versions. But is there a reason to disable
>>soft-upgrade, with loud and clear warnings about software being *ALPHA
>>*quality and we mean that at the download site?
> 
> 
> The restriction is there to avoid accidental booting of an alpha/beta
> version of derby against a production database. The risk with alpha/beta
> software is that soft-upgrade could be broken and leave the production
> database in a state where it could not be used with the previous release.
> 
> One option, as you say, would be to remove all restrictions and let
> folks find bugs, and it's their own fault if they boot an alpha database
> against a production database.
> 
> I also wonder how backup plays into this, can I restore a 10.0 backup
> with a 10.1 engine (10.1 with 10.2 etc.)? That would be one way for your
> customers to work around having to export & import data. That could be a
> step to making a new alpha/beta release more accessible to existing
> users, allow testing based off an backup.
> 
> Dan.
> 
> 
> 

My two cents:

Although everyone goes crazy if uprade does not work off-the shelf, I 
think it is worth preventing accidental booting of prodction database 
with an alpha(or one cut from active codeline) release. Main reason is :

    1) I think there is little testing done on an active code line to 
make sore database can be reverted back to old releases successfully.

    2) derby does not have support for reverting to an old release 
once an  hard upgrade is done.

Restoring from a old engine backup to a new engine will not work. It 
will fail for same reason an upgrade is failing.

Instead of using export & import of data to a new engine,  users can 
restore from the backup on the same version of the engine at diffent 
location and then do the testing by setting 
"derby.database.allowPreReleaseUpgrade=true"


Thanks
-suresh





Mime
View raw message