db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Can't upgrade from 10.1 to 10.3
Date Wed, 06 Jun 2007 21:30:35 GMT

Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> SNAG: I found this can happen when upgrading from 10.1 to 10.3:
>
>   - 10.1 database created with authentication on
>   - in 10.1 or in soft upgrade mode with 10.3,
>     set sqlAuthorization to true by calling SYSCS_SET_DATABASE_PROPERTY.
>   - shut down
>   - the database now refuses to boot unless hard upgrade is specified.
>     That is, it will not do a soft boot as long as the property
>     derby.database.sqlAuthorization is true.
>
>     ERROR XCL47: Use of 'sqlAuthorization' requires database to be
>                  upgraded from version 10.1 to version 10.2 or later.
>
>     It can still be booted in 10.1, of course.
>   - This behavior is the same for 10.1 -> 10.2, btw.
>
>   - Now, in 10.3 with DERBY-2264, when the user has specified hard
>     upgrade, in order to verify that the user is dbo and thus allowed
>     to upgrade, we boot first *without* the upgrade attribute to check
>     credentials (i.e. a soft boot), and if OK, shutdown and reboot
>     with hard upgrade.  Unfortunately, the first boot will now fail,
>     since soft boot is barred by the sqlAuthorization being set. But
>     the user *is* attempting a hard upgrade, so the error message is
>     meaningless.
>
> I see two options for handling this:

I came up with option 3) which I think is preferrable:

3)  When doing temporary soft upgrade boot used to authenticate (first
    phase of two phased hard upgrade boot in DERBY-2264), make sure
    not to check for/activate any new feature (in casu
    SQLAutorization) in DataDictionaryImpl#boot /
    DataDictionaryImpl#checkVersion.

    This ensures that the temporary soft upgrade boot will succeed so
    authentication and hard upgrade boot can proceed.

    I propose to bypass the feature check/activation in
    DataDictionaryImpl#boot by passing in an internal attribute
    'softUpgradeNoFeatureCheck' (from EmbedConnection) when required.

    As a consequence, when upgrading from 10.1 or earlier to 10.3 or
    later, there will be no check for *database owner* (OK, since
    database owner is not yet in created in its post 10.1 form), but
    an ordinary credentials check will happen before the hard upgrade
    takes place (nice) - so only an authenticated user can upgrade and
    become database owner (always assuming authentication is enabled
    of course), allowing us to still avoid
    https://issues.apache.org/jira/browse/DERBY-2766
    "Non-authenticated user gets to upgrade from pre-10.2 version
    databases and become database owner".

    The second phase will then do the hard upgrade and, if it is from
    a pre-10.2 database, create the (new) database owner - as before
    with upgrade to 10.2.

    Question: Is passing an internal attribute down from
    EmbedConnection to DataDictionaryImpl#boot an acceptable way to
    implement this solution?  (I do make sure to remove any such
    attribute for other cases, in case somebody tries to be clever and
    pass it in from the URL..)

    I tested this approach and it works for the ad hoc tests I have
    been able to imagine and throw at it.

    I plan to make a new patch for DERBY-2264 with this solution.

Dag

>
> 1)  Make the exception XCL47 specific to the sqlAuthorization feature
>     and catch it when the credentials boot fails, then throw a more
>     meaningful error message asking the user to unset the
>     sqlAuthorization property before attempting upgrade.
>
>     Cons: step back from 10.2, which handled the hard upgrade
>           maybe be awkward to have to reboot in older release to fix
>           it.
>     Pros: simple fix
>
> 2)  Make the exception XCL47 specific to the sqlAuthorization feature
>     and catch it when the credentials boot fails, realizing that this
>     is an upgrade from a release prior to 10.2 (for which dbo powers
>     enforcement is not really meaningful); and go ahead with the hard
>     upgrade as requested, falling back on checking credentials after
>     boot time, as in 10.2.
>
>     Pros: Principle of least surprise; do what user asks.
>     Cons: May lead user to think dbo powers checking was indeed
>     performed when it was not.


>
> I think I prefer solution 2); the dbo powers checking could be seen as
> providing a guarantee for future upgrades, it is not obvious that it
> would or should apply to upgrades from older versions anyway.
>
> Thoughts?
>
> Dag

Mime
View raw message