[DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

[Nick Vatamaniuc <va...@apache.org>]

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).

Re: [DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

[Nick Vatamaniuc <va...@gmail.com>]

Agree, "uuid" is a better name.

On Tue, May 26, 2020 at 2:38 PM Paul Davis <pa...@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 <va...@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).

Re: [DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

[Paul Davis <pa...@gmail.com>]

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 <va...@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).