Subject Re: [Firebird-Architect] Major and Minor ODS Versions
Author Jim Starkey
Vlad Khorsun wrote:
>> Oh, by the way, more lives have been ruined by unsuccessful "updates in
>> place" than any other bad idea in databases. There's nothing like a
>> "can't go forward and can't go back" to mess up a morning. Automatic
>> conversions on first reference are very, very dangerous (go ahead, ask
>> me how I know).
>>
>
> So, how you know ? ;)
>

Experience, my friend. To avoid changing the major ODS, sometimes
irreversible one time changes are necessary. But you blow one (and I've
blown many) and you have to do a quickie one-off to rescue somebody's
off-line database, you tend to remember it.

I'm really arguing two contradictory things. One is that if at all
humanly possible, databases should be upwards compatible. The other is
that when progress requires a change, an incompatible upgrade is
required, and a strategy should be in place from day one to handle that
case.

Interbase and Rdb/ELN used Y-valves to run old engines. To avoid symbol
conflicts, Interbase packaged the previous version engine as a "pipe
server" that ran out of process. Falcon doesn't have a Y-valve, but
I've avoid a major ODS change since 2002 (I am either getting smarter or
less ambitious), but this required two parallel sets of index code (one
for legacy Netfrastructure indexes and new Falcon indexes). The Falcon
guys are currently have this same debate over major/minor version change
to support new index key format. The break down is the same -- the old
farts want to preserve existing databases and the young jackasses want
wipe the slate clean and start over.

Nimbus doesn't have an ODS, so it doesn't have major and minor version
numbers. Messages and serialized objects contain a format version
number, and all versions understand all old formats. A Nimbus cloud
runs at the oldest version number of a server in the cloud. When the
last server with an old version number leaves the cloud, the cloud
spontaneously kicks up to the oldest version present in the cloud. A
node running an older version simply can't join a cloud running at a
newer version. The "net" (pun intended) result is that Nimbus clouds
don't go down for software upgrades -- nodes are upgraded piecemeal
until the whole cloud is running a new version.