couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: [DISCUSS] Minor replicator error reporting API change
Date Sat, 21 Dec 2019 13:02:55 GMT
+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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message