Rick Hillegas wrote:
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?
I am not sure if there are general rules that can for sure tell you if
a change is OK or not... Some amount knowledge of how older systems
work is needed.
So far I
have seen only two examples of "safe" changes
o changing the nullability of a system column
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)
Here is one concrete example... I changed all system schemas from being
owned by pseudo-user 'DBA' to actual authorizationId of database
creator (also DBA) in sysschemas. While I am only doing this in full
upgrade mode, I could potentially move this to cover even soft-upgrade
(if needed... there is no need actually). This change is "safe" because
10.1 wasn't using authorizationId column of system schemas and by
putting some useful value in 10.2 in soft-upgrade mode, you wouldn't
break 10.1.
Some other safe changes are:
- Changing of some system catalog values. Mamta's feature ALTER
TABLE <tableName> ALTER COLUMN <colName> RESTART WITH
<newIdentityValue> changed identity column values in syscolumns.
This is a safe change in soft upgrade also, because by reverting to
10.1, this shouldn't cause any problems for 10.1 server.
- Adding new builtin functions, like ceil()/floor() etc. Since
these don't leave any disk prints, they may be ok. One question is what
if someone creates a view in soft upgrade mode using new builtin
functions and after downgrading the view could fail.
Satheesh
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.
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
Regards,
-Rick
|
