You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2006/03/16 18:18:04 UTC
Soft Upgrade question
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?
Thanks,
-Rick
Re: Soft Upgrade question
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Oystein Grovlen - Sun Norway wrote:
>
>> 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"
>
>
> I tried to find a description of this property, but was not able to.
> Can this be use to be able to upgrade from alpha to GA?
>
I think this property was designed mainly for Derby developers to test
their upgrade code during development phase. I don't think this property
should be exposed, in current form, to users... since this property also
allows full upgrade in addition to soft upgrade from previous GA
releases to ALPHA releases. To get balance between need to get early
testing for ALPHA releases and need to protect production databases, may
be we could alter the property so allow 'softUpgrade' or 'fullUpgrade'
values, like:
derby.database.allowPreReleaseUpgrade=softUpgrade|fullUpgrade
If the property is not set, Derby could reject either form of upgrades
to ALPHA/BETA releases. SoftUpgrade option would only allow soft upgrade
to pre-release versions and fullUpgrade would allow hard upgrade as
well. Then may be this property can be documented and strongly
discourage use of fullUpgrade, except for Derby developers.
Satheesh
Re: Soft Upgrade question
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
> 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"
I tried to find a description of this property, but was not able to.
Can this be use to be able to upgrade from alpha to GA?
--
Øystein Grøvlen
Re: Soft Upgrade question
Posted by Suresh Thalamati <su...@gmail.com>.
Daniel John Debrunner wrote:
> Satheesh Bandaram wrote:
>
>
>>
>>Deepa Remesh wrote:
>>
>>
>>>On 3/16/06, Rick Hillegas <Ri...@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
Re: Soft Upgrade question
Posted by Daniel John Debrunner <dj...@apache.org>.
Satheesh Bandaram wrote:
>
>
> Deepa Remesh wrote:
>
>>On 3/16/06, Rick Hillegas <Ri...@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.
Re: Soft Upgrade question
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Jean T. Anderson wrote:
> Satheesh Bandaram wrote:
>>Deepa Remesh wrote:
>>>On 3/16/06, Rick Hillegas <Ri...@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.
>
> would DdlUtils help them then?
>
> http://db.apache.org/derby/integrate/db_ddlutils.html
But DdlUtils isn't a silver bullet. :-) I see it as most useful for a
customer who wants to make a copy of the current production database and
migrate it to an alpha/beta version of Derby to test the new release.
But if a user produces a database on an alpha/beta Derby release, then
wants to migrate that database to the official Derby release, there
could still be problems. For example, if the users takes advantage of a
feature in the alpha/beta release that drops out of the final official
release, for whatever reason, that part of the migration won't work.
-jean
<snip>
Re: Soft Upgrade question
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Satheesh Bandaram wrote:
>
> Deepa Remesh wrote:
>
>>On 3/16/06, Rick Hillegas <Ri...@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.
would DdlUtils help them then?
http://db.apache.org/derby/integrate/db_ddlutils.html
-jean
> 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?
>
> Satheesh
>
>>
>>Upgrades to alpha/beta versions are not supported by default. For
>>testing purposes, we can specify a system property
>>"derby.database.allowPreReleaseUpgrade" to true to allow upgrade to
>>pre-release version. Please take a look at the upgrade tests where
>>this property is used.
>>
>>Thanks,
>>Deepa
>>
>>
>>
>>
>>
Re: Soft Upgrade question
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>So if soft upgrade with alpha is run against an existing database are
>you saying that database should not longer be accessible by any released
>version of Derby?
>
Yes I think this is best. Once you upgrade to the pre-release version,
you cannot go back to 10.1 or up to 10.2
>Just trying to understand what your definition of
>"modified" is in this case.
>
>
>
Basically modified would mean that the database has run some risk of
corruption because of exposure to pre-release software that it might
carry with it when it moves to the supported versions. Allowing a
database to go to a release version after alpha exposure means cases
could come in for corrupted databases that once upon a time were
corrupted by alpha software. Nobody will know that was what caused it
because when the case is reported, sysinfo only shows the current
supported version.
I think that what we want to provide is an easy way to try out
pre-release software on a *copy* of your database but make sure that
copy doesn't ever end up in production. I was disappointed that the
restore from a 10.1 db wouldn't work as it would have provide an
intuitive interface for this.
Kathey
Re: Soft Upgrade question
Posted by Daniel John Debrunner <dj...@apache.org>.
Kathey Marsden wrote:
> Satheesh Bandaram wrote:
>
>
>>I find current behavior inconvinient... I am trying to understand why Derby
>>doesn't allow soft-upgrade from previous releases.
>>
>
> Regardless of whether we provide a mechanism allow soft upgrade, I
> think that databases that have been modified by alpha software should
> not be accessible by a released Derby version and thus be allowed carry
> any undetected corruption with them into a supported production
> environment where we really can't tell that it was the alpha software
> that did the damage.
So if soft upgrade with alpha is run against an existing database are
you saying that database should not longer be accessible by any released
version of Derby? Just trying to understand what your definition of
"modified" is in this case.
I wonder why if the alpha/beta checks were removed in one direction, why
they would not be removed in the other direction? Not sure I'm in favor
of removing any of the restrictions, but it seems strange to disallow
some things and not others. Either we try to protect users or we say
it's open source, use the alpha/beta at your own risk, anything could
happen.
Thanks,
Dan.
Re: Soft Upgrade question
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Kathey Marsden wrote:
> Regardless of whether we provide a mechanism allow soft upgrade, I
> think that databases that have been modified by alpha software should
> not be accessible by a released Derby version and thus be allowed carry
> any undetected corruption with them into a supported production
> environment where we really can't tell that it was the alpha software
> that did the damage.
>
> So whatever mechanism we provide to allow that should clearly
> communicate that this copy of the database is never going to see a
> production Derby release again.
I agree that this should be the default behavior, but I think we should
provide a mechanism that makes it possible to override this restriction.
If users are willing to take this risk, why should be prevent them for
doing so?
--
Øystein Grøvlen, Senior Staff Engineer
Sun Microsystems, Database Technology Group
Trondheim, Norway
Re: Soft Upgrade question
Posted by Kathey Marsden <km...@sbcglobal.net>.
Satheesh Bandaram wrote:
>I find current behavior inconvinient... I am trying to understand why Derby
>doesn't allow soft-upgrade from previous releases.
>
Regardless of whether we provide a mechanism allow soft upgrade, I
think that databases that have been modified by alpha software should
not be accessible by a released Derby version and thus be allowed carry
any undetected corruption with them into a supported production
environment where we really can't tell that it was the alpha software
that did the damage.
So whatever mechanism we provide to allow that should clearly
communicate that this copy of the database is never going to see a
production Derby release again.
Kathey
Re: Soft Upgrade question
Posted by Deepa Remesh <dr...@gmail.com>.
On 3/16/06, Rick Hillegas <Ri...@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?
>
Upgrades to alpha/beta versions are not supported by default. For
testing purposes, we can specify a system property
"derby.database.allowPreReleaseUpgrade" to true to allow upgrade to
pre-release version. Please take a look at the upgrade tests where
this property is used.
Thanks,
Deepa