Subject | RE: [Firebird-Architect] HEAD branch and ODS changes |
---|---|
Author | Leyne, Sean |
Post date | 2003-07-30T21:22:34Z |
Jim,
I thought of this when Nickolay and I were discussing the implementation
of the new backup scheme, which prompted the whole delta/difference file
discussion.
The UID came up as a way to ensure that an incremental backup could only
be applied to the master database with the same UID -- nothing like
applying the wrong backup to really trash a database!!!
In fact, as UID should probably be used identify the last incremental
backups made for a database -- with each backup getting a UID. The
database would then track the UIDs of most recent/valid
incremental/valid backups.
At the very least a UID would be a "good thing" should we ever want to
create a manager process (or LDAP service) which would "register" and
control databases servers and files.
Sean
> While we're in the area, has anyone given any thought toYes, me! ;-)
> 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.
I thought of this when Nickolay and I were discussing the implementation
of the new backup scheme, which prompted the whole delta/difference file
discussion.
The UID came up as a way to ensure that an incremental backup could only
be applied to the master database with the same UID -- nothing like
applying the wrong backup to really trash a database!!!
In fact, as UID should probably be used identify the last incremental
backups made for a database -- with each backup getting a UID. The
database would then track the UIDs of most recent/valid
incremental/valid backups.
At the very least a UID would be a "good thing" should we ever want to
create a manager process (or LDAP service) which would "register" and
control databases servers and files.
Sean