Daniel John Debrunner wrote:
Satheesh Bandaram wrote:
Deepa Remesh wrote:
On 3/16/06, Rick Hillegas <[EMAIL PROTECTED]> 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
