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


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