Adriano dos Santos Fernandes wrote:

> You again on this about minor vs major / you vs Borland... This make me
> think:
>
> 1) Accordingly to you (and the way FB works now), minor ODS change can't
> be opened by engine with handle same major but less minor version. So
> from this POV, minor vs major is the same thing.
>
> 2) There is some things called OOP, interfaces and abstractions, I
> believe you're forgetting it or just want to make an use-case for
> multiple providers. Let's say, we discover our indexes are wrong or slow
> for some cases. We create a new index representation on disk. This would
> be "a major ODS change", and now requires two engines to be developed,
> QAed, with much more chances to dangerous. It's much better to create an
> interface that handle it, point it on the Database class accordingly to
> the ODS version, in *one* engine, and get on with life...
>

No, it is not necessary to change the major ODS version for indexes.
All that is necessary is for an engine to code to handle the new and old
formats and a mechanism to tell one from another.

The multi-segment key format we talked about last week is an excellent
case in point. Because the difference is in the key format, not the way
keys are compared, the index management code doesn't need to change.
Existing indexes could continue to work the way they were built, but new
indexes would be created with the new format. This would require
bumping the minor ODS version number, not the major one.

In specific, last time I looked, Firebird had a RDB$INDEX_TYPE field in
RDB$INDICES, now used to indicate descending indexes. If the minor ods
version were bumped, it could be redefined to hold both a key format and
the descending bit. Old versions of Firebird wouldn't understand it,
but that's what the minor version number is for. A new version of time
would pick up the key format version number at metadata load time, and
generate keys accordingly.

The point is this: Changing the major ODS version means supporting an
old engine and should be avoided if at all possible. Most changes can
and should be handled with the minor ODS version number. But sometimes
the price of progress is incompatibility, and that's what the major
version number is for. The architecture is there to hide most of the
unpleasantness from the user.

This are really not hard problems to solve, but they do require some
thinking and planning.

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).

>
> Adriano
>
>
> Jim Starkey escreveu:
>
>> Helen Borrie wrote:
>>
>>
>>> At 02:13 PM 25/02/2009, Jim Starkey wrote:
>>> [ ..
>>> ..
>>> ..
>>> ..]
>>>
>>> N.I.H. in spades - Classic Wolf! ;-)
>>>
>>>
>>>
>> NIH? As in, "Not Invented here"? That's a pretty peculiar brickbat to
>> hurl give a) I created it the first place, b) I was applauding Sean for
>> suggesting a change to fix a problem I originally created. Helen, you
>> aren't, by any chance, off your meds again?
>>
>> Anyway, here was the Interbase originally worked and Vulcan restored.
>> The issue is how to handle a major (and incompatible) change to database
>> format. Lets assume that an existing engine handles an ODS version
>> major X and a new, improved engine handles ODS Y. The strategy is as
>> following:
>>
>> 1. The Y-valve is configured with both engines X and Y.
>> 2. A user of X installs new Firebird version Y. The X engine is
>> retained (or part of the kit)
>> 3. When application attaches a database, the Y-valve first passed the
>> attachment to engine Y which can't open it and returns an error.
>> The Y-valve then tries engine X, which successfully attaches the
>> database.
>> 4. So, despite the software upgrade, existing databases continue
>> unchanged.
>> 5. When the user is happy with version Y, he backs up and restores
>> his database. This creates a new Y version of his database,
>> leaving both a backup and an intact X version of the database in
>> case reversion is required.
>> 6. Nothing needs to be changed in the application during the
>> transition from X to Y. It just works.
>>
>> This worked very well. Changes to the system tables usually required a
>> major ODS change (another post on that, later), so this saved our
>> Interbasian butts more than once.
>>
>> Borland pretty much screwed up the multiple engine bit when they did
>> their half-ass implementation of SQL in the Y-valve rather than moving
>> SQL into the engine where it belonged.
>>
>> Vulcan restored, cleaned up, and extended the Y-valve architecture into
>> what became known as the provider architecture. It's still there,
>> sitting on the shelf.
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376