Dmitry, > > Consider: I want to restore a copy of my production database to my testing > system and have the same UUID as Live because I have defined a number of > config/operational values based on the UUID. > > Consider: I have a replication set up with replica B linked to source database > A via UUID. Now I restore a copy C of my production database A to my > testing system and forget to change the replication config. Then I start > playing with database C and my replica B becomes invalid.
Yes, and "stupid is as stupid does". Seriously, if we are talking about UUID for replication purposes, I don't think the UUID will be enough -- it does not provide enough granularity. I think some other/additional value will be required, perhaps a 'last update' or 'version' UUID/timestamp to ensure that only the appropriate replication source can be used for given replicas. > There are different usage scenarios for database UUID and they may require > supporting them in different ways. This is why I don't want to see it > committed "now". This is somewhat not so trivial as appears at the first > glance. I don't think it will be possible for us to arrive at a set of answers that would satisfy all possibilities. IMO, supporting the different modes would be about ensuring that the correct tools (such as gfix or ALTER DATABASE) are available for the developer to apply the changes as they need. I am fine with waiting (for a little while) for UUID, just as long as UUID and Crypt Database ID are understood to be separate values. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
