couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Vatamaniuc <vatam...@gmail.com>
Subject Re: [DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0
Date Tue, 26 May 2020 19:03:08 GMT
Agree, "uuid" is a better name.

On Tue, May 26, 2020 at 2:38 PM Paul Davis <paul.joseph.davis@gmail.com> 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 <vatamane@apache.org> 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).

Mime
View raw message