I'd be fine with either failing the request or fallback to null. But
fallback to 0 sounds surprising and against intuition to me.
Best,
Xintong
On Wed, Jul 26, 2023 at 7:44 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> We discussed this in FLINK-29863[1] as well. While the JSO
We discussed this in FLINK-29863[1] as well. While the JSON standard
doesn’t specify using null, the JavaScript standard encoding function
writes these values as null[2]. I think this will be least surprising to
users, and agree with the other points in this direction.
Best,
Austin
[1]: https://i
>
> Then we'd break the API for users that did already apply workarounds
> although the user hasn't done anything wrong.
That argument would also work against introducing the 0 default value. If
users have a workaround, introducing 0 might break their setup because they
might have used a different
Then we'd break the API for users that did already apply workarounds
although the user hasn't done anything wrong.
On 25/07/2023 04:31, Xintong Song wrote:
we should treat these cases as errors
Looking at the fields listed in the FLIP, I'd agree with this argument. And
based on this, shouldn'
>
> we should treat these cases as errors
>
Looking at the fields listed in the FLIP, I'd agree with this argument. And
based on this, shouldn't we fail the request with e.g., a status code 500,
rather than responding with a fallback value silently?
Best,
Xintong
On Tue, Jul 25, 2023 at 12:22
We might consider using 0 as null for values that never return 0. But null
is still not equal to 0 and it will be very difficult to let every
contributor in this community follow this rule, especially for future
unknown APIs, which means there will be some cases that still need null.
Personally, I
The downside to null is that it again forces users to handle this case
themselves.
The reality is that there is no good default value.
Ideally we fix all cases where we return such values, such that the
fallback to 0 isn't even used.
Arguably the same could be said for null, but I'd think that
I agree that it's a bit strange to have 0 as a fallback value because it
can also naturally occur for many metrics.
If we want to omit the value null would be probably better as Matthias
suggested.
Gyula
On Mon, Jul 24, 2023 at 4:02 PM Matthias Pohl
wrote:
> What was the reason you decided to g
What was the reason you decided to go for 0 as the fallback value instead
of null? Wouldn't that be a more reasonable value for error cases?
On Mon, Jul 24, 2023 at 12:51 PM Chesnay Schepler
wrote:
> There are a number of cases where the REST API can return infinity or
> NaN for certain double f
There are a number of cases where the REST API can return infinity or
NaN for certain double fields.
This is problematic because the JSON spec does not allow such values,
and tooling working against that spec may run into issues when
encountering such a value.
Specifically we've seen this be
10 matches
Mail list logo
