couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Vatamaniuc <vatam...@gmail.com>
Subject Re: [DISCUSS] Minor replicator error reporting API change
Date Sun, 22 Dec 2019 07:19:10 GMT
Good point regarding Fauxton, Garren.

Thank you for taking a look at it

I've created the PRs for the implementation and the docs:

https://github.com/apache/couchdb/pull/2379
https://github.com/apache/couchdb-documentation/pull/465

On Sat, Dec 21, 2019 at 8:03 AM Garren Smith <garren@apache.org> wrote:
>
> +1 nice improvement. We will have to check and possibly update Fauxton
> based on this change.
>
> Once this change is ready to go I can check Fauxton and make sure we
> support it or make any required changes.
>
> On Fri, Dec 20, 2019 at 8:47 PM Arturo GARCIA-VARGAS <arturo@ficuslabs.com>
> wrote:
>
> > +1 - It makes sense for any error object to have an error key
> >
> > On 20 December 2019 18:33:04 GMT+00:00, Nick Vatamaniuc <
> > vatamane@apache.org> wrote:
> > >Hi everyone,
> > >
> > >Before 3.0 goes out, I wanted to propose a minor replicator
> > >_scheduler/* API change.
> > >
> > >Currently when a replication job is crashing it reports the error as a
> > >string in the "info" field. So that that "info" field can be null, a
> > >string, or an object with various replication stats.
> > >
> > >The proposal is to turn the string into an object as well with an
> > >"error' field. So instead of
> > >
> > >{
> > >  ...
> > >   "info": "some error message"
> > >}
> > >
> > >It will look like
> > >
> > >{
> > >   ...
> > >   "info": {"error": "some error message"}
> > >}
> > >
> > >A few reasons for this change that it's a bit more consistent, and it
> > >should help with the some clients in static type language which have
> > >harder time handling an object being either a string, or an object, as
> > >opposed to a nullable fields and be different objects.
> > >
> > >What does everything think?
> > >
> > >Cheers,
> > >-Nick
> >

Mime
View raw message