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 the last summit:
https://github.com/apache/couchdb/issues/1502
Could we consider this use case at the same time?
-Joan
On 2019-05-16 2:51 a.m., Garren Smith wrote:
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 remain the same and
any requests to the design doc url automatically get the latest views only
once they built.
This is an effective way of managing building large indexes, but the
process is quite complicated and often users get it wrong. I would like to
propose that we move this process into CouchDB and let CouchDB handle the
actual process. From a users perspective, they would add a field to the
options of a design document that lets CouchDB know, that this build needs
to be built in the background and only replace the current index once its
built:
```
{
"_id": "_design/design-doc-id",
"_rev": "2-8d361a23b4cb8e213f0868ea3d2742c2",
"views": {
"map-view": {
"map": "function (doc) {\n emit(doc._id, 1);\n}"
}
},
"language": "javascript",
"options": {
"build_and_replace": true
}
}
```
I think this is something we could build quite effectively once we have
CouchDB running on top of FoundationDB. I don’t want to implement it for
version 1 of CouchDB on FDB, but it would be nice to keep this in mind as
we build out the map/reduce indexes.
What do you think? Any issues we might have by doing this internally?
Cheers
Garren
