If a user didn't specify the index they wanted to use, leaving the choice of index up to CouchDB, I would expect Couch would ignore the partially built index and fall back on _all_docs. so +1 on this.
But we need also consider the API response if a user *specifies* an index during a query (with use_index) when that index is not built yet, I think I would prefer an instant 4** response indicating that the requested resource isn't ready yet, rather than performing a very slow, _all_docs-powered search. Is "425 Too Early" a suitable response? On Mon, 23 Mar 2020 at 23:30, Joan Touzet <woh...@apache.org> wrote: > > > On 2020-03-23 4:46 p.m., Mike Rhodes wrote: > > Garren, > > > > Very much +1 on this suggestion, as it is, at least for me, what I'd > expect to happen if I were leaving the system to select an index -- as you > imply, the build process almost certainly takes longer than using the > _all_docs index. In addition, for the common case where there is a less > optimal but still useful index available, one might expect that index to be > used in preference to the "better" but unbuilt one. > > I agree. > > > But I do think this is important: > > > >> We can amend the warning message > >> to let them know that they have an index that is building that could > >> service the index when it's ready. > > > > Otherwise it's a bit too easy to get confused when trying to understand > the reason why an index you were _sure_ should've been used in fact was not. > > Question: Imagine a node that's been offline for a bit and is just > coming back on. (I'm not 100% sure how this works in FDB land.) If > there's a (stale) index on disk, and the index is being updated, and the > index on disk is kind of stale...what happens? > > -Joan >
