Option C is a nice idea. But it’s more work than I have time to do right
now. I’m going to go with option A. Later it would be nice to consolidate
all errors in search, map/reduce and mango and create error endpoints for
all of them.
Cheers
Garren
On Thu, Jan 16, 2020 at 9:01 PM Benjamin Anderson
I think Adam’s been suggesting Option C for close to ten years now - maybe it’s
a good time to pick it up before users are trained to look at something else.
--
b
> On Jan 16, 2020, at 13:31, Robert Newson wrote:
>
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 wrote:
>
> Right. I sort of assumed an additional endpoint, someth
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 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 a
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
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 wrote:
>
> For A y
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 wrote:
>
> Hi Everyone,
>
> We want to impose limits on
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
For anyone that is interested in following along on this. I have an initial
PR https://github.com/apache/couchdb/pull/2456
This isn't feature complete yet. I've written on the PR the current state
of the work and the type of feedback I'm looking for now.
Cheers
Garren
On Wed, Oct 23, 2019 at 3:50
