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