Option A matches our behaviour for other (persistent) errors during indexing and gets my vote.
Surfacing view build errors (option C) is certainly better but is obviously more work. > On 16 Jan 2020, at 16:09, Adam Kocoloski <a...@kocolosk.net> wrote: > > Right. I sort of assumed an additional endpoint, something like > > GET /db/_design/ddoc/_errors > > Adam > >> On Jan 16, 2020, at 10:56 AM, Garren Smith <gar...@apache.org> wrote: >> >> Option A is similar to what we do currently when a doc fails to be mapped >> and a user/admin would see the errors in the log. >> >> Keeping an index is a nice idea, >> But what do we do with it? How would we expose that to the user? I’m >> guessing we would have to add a new api endpoint or add it to the _info >> endpoint >> >> >>> On Thu, Jan 16, 2020 at 5:35 PM Adam Kocoloski <kocol...@apache.org> wrote: >>> >>> Option C - keep a separate index of document IDs that failed indexing. >>> >>> I could be convinced of either Option C or Option A, and tentatively agree >>> with Paul that the document indexing ought to be atomic for an entire view >>> group. >>> >>> Adam >>> >>>> On Jan 16, 2020, at 9:48 AM, Paul Davis <paul.joseph.da...@gmail.com> >>> wrote: >>>> >>>> For A you also want to consider multiple emitted K/Vs on whether we >>>> index some or none. I'd assume none as that would match the existing >>>> equivalent of a doc throwing an exception during indexing. >>>> >>>>> On Thu, Jan 16, 2020 at 8:45 AM Garren Smith <gar...@apache.org> wrote: >>>>> >>>>> Hi Everyone, >>>>> >>>>> We want to impose limits on the size of keys and values for map indexes. >>>>> See the RFC for full details - >>>>> https://github.com/apache/couchdb-documentation/pull/410 >>>>> >>>>> The question I have is what is the best user experience if the user does >>>>> exceed the key or value limit? >>>>> >>>>> Option A - Do not index the key/value and log the error >>>>> >>>>> Option B - Throw an error and don't build the index >>>>> >>>>> Option C - Any other ideas? >>>>> >>>>> Cheers >>>>> Garren >>> >>> >
