Agree, "uuid" is a better name.
On Tue, May 26, 2020 at 2:38 PM Paul Davis <[email protected]> wrote: > > We already have the uuid generated. I'd suggest just adding a `uuid` > field that exposes it. > > On Tue, May 26, 2020 at 1:27 PM Nick Vatamaniuc <[email protected]> wrote: > > > > Hi everyone, > > > > I was wondering if we could expose an "instance_id" field in the top > > level `/<db>` (db_info) result. The value would be a uuid which is > > unique for every database instance. That is, if a database is deleted > > and re-created with the same name, it would have a different > > "instance_id". [*] > > > > We'd get at least 2 benefits from it: > > > > 1) Replicator could eventually could be updated to checkpoint on the > > target only, and thus have a read-only access to the source. Currently > > we need to checkpoint on the source to account for the case when the > > source db has been recreated, so we maintain the checkpoint history on > > the source and the target. > > > > 2) User's code might want to know if it the database has been > > recreated, mostly to avoid mishaps when they continue performing > > requests against the db with the same, which now may have completely > > different data in it. > > > > What do we think, do we like this idea? > > > > Cheers, > > -Nick > > > > [*] Back in 1.x we had the "instance_start_time" field which does > > mostly same thing, but is based on time. In 2.x and 3.x we still emit > > that field and for compatibility and hard code it to "0". We could > > re-use that field, but I think since the idea is to make it a uuid and > > not a timestamp so it's name doesn't quite match and it would have a > > different format (64bits vs 128bits).
