Ann Harrison wrote:

>Hello Nickolay,
>
> OK, if the code name for V2.0 is 1.6, then I've got no problem with
>ODS changes. And yes, you're right, multi-page header pages were
>introduced with logging. And yes, they seem pretty dangerous to me,
>since the original code assumed it could read the header page without a
>handoff. Sigh.
>
>

Sorry for sticking my nose in late in the discussion, but I don't follow
the development list. I think I understand the proposed scheme, but
could use a quick recap. If I understand it correctly, it sounds like a
very clever scheme which, with perhaps a tweak or two here and there,
could have a few other interesting uses as a read/write wrapper around a
readonly database. This could be quite interesting for access to a
database distributed on a CDROM. Or for debugging a database without
destroying the test vehicle. All sorts of interesting uses come to mind.
However, these things won't allow an update to the database header page.

I think it might make sense to consider alternatives to using the
database header page. There are many alternatives. A rather nifty
scheme would be to dump the database file name to identify a database in
favor of some sort of registry, which could easily contain the name of
an active wrapper file if one is active. There would need to be a way
to communicate between a registry update and the database server and/or
classic instances to allow dynamic changes. There are lots of other
possible implementations, of course.

While we're in the area, has anyone given any thought to creating a UID
at database creation time that could be stored on the header page and
used as the root for the database lock tree? This would be a very nice
(though partial) solution to the database alias problem.