>From all the messages in this thread, it sounds like there are two basic forms
>of change to indexes here:
- Backwards compatible change (e.g., adding a field to the emitted value where
the consumer is agnostic to new fields).
- Backwards incompatible changes.
I think the automatic replace
If the consuming code can’t handle the switchover, the user should not be
asking couchdb to build an incompatible index in the first place, but certainly
shouldn’t ask couchdb to replace an index automatically (i.e, they should not
use our proposed new handling at all).
On replication, the doc
Stefan raises some really good points. Should we rather have an extra step
where the user can tell CouchDB when to do the switch over?
We could use the _info endpoint to indicate which design doc is currently
being used and which is being built. And even if the new design doc is
built.
Otherwise
> On 16. May 2019, at 23:03, Robert Samuel Newson wrote:
>
> I suggest an alternative; the new design document could include the _id of
> design document it’s replacing (“_replaces”:”_design/foo”). On completion of
> the view build of the new design document, CouchDB itself updates the
Looks great, but how that shadow ddoc would replicate?
What happens when tgt node received shadow ddoc, rebuilt shadow index, and
then updates original ddoc?
ermouth
пт, 17 мая 2019 г. в 00:03, Robert Samuel Newson :
> I suggest an alternative; the new design document could include the _id of
I suggest an alternative; the new design document could include the _id of
design document it’s replacing (“_replaces”:”_design/foo”). On completion of
the view build of the new design document, CouchDB itself updates the named _id
to the same content as the new design document (strictly, only
+1 on solving this for all users, and same caveats as Stefan raises :)
> On 16. May 2019, at 09:38, Stefan du Fresne wrote:
>
> Hey Garren,
>
> Having this a native part of CouchDB seems like a really cool idea: we have
> automated the manual dance you're talking about with our deployment
Hi Garren,
+1. I actually went hunting in GitHub for an issue on this, and can't
find one. It probably goes back to JIRA, and I don't have the energy to
dig through that now.
The closest issue that captures this is the same thing - but for
*databases* - and is on our official roadmap from
Hey Garren,
Having this a native part of CouchDB seems like a really cool idea: we have
automated the manual dance you're talking about with our deployment tooling,
but it would be really nice not to have to!
I'm not clear how it would work though, at least in terms of coherent
deployments.
Hi Everyone,
A common pattern we see for updating large indexes that can take a few days
to build, is create a new design docs with the new updated views. Then once
the new design doc is built, a user changes the new design doc’s id to the
old design doc. That way the CouchDB url for the views
10 matches
Mail list logo
