Skip to content

Wrong variable "var" for the Scalar "Float" if value is greater than 10^15 #47

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
no1seman opened this issue Mar 30, 2022 · 0 comments · Fixed by #49
Closed

Wrong variable "var" for the Scalar "Float" if value is greater than 10^15 #47

no1seman opened this issue Mar 30, 2022 · 0 comments · Fixed by #49

Comments

@no1seman
Copy link

No description provided.

Totktonada added a commit that referenced this issue Apr 1, 2022
It is quite usual that a floating point number is encoded using JSON,
goes over HTTP, received on tarantool server, decoded from JSON and
passed as a variable into the GraphQL executor.

A number out of the [-10^14+1; 10^14-1] range is decoded into Lua as
cdata number[^1] to don't loss the precision. A JSON decoder don't know
that we intend to use this value as the floating point one and chooses
the conservative option: decode the value into cdata number to don't
loss the precision.

In GraphQL we know that it is actually the floating point value
(disregarding its representation in Lua). So it looks correct to accept
a cdata number as value of a Float variable.

The similar idea was expressed in [1] against tarantool itself: let it
accept a number without fractional part as a value suitable for the
`float` field type.

[1]: tarantool/tarantool#5933

[^1]: `cdata<int64_t>` or `cdata<uint64_t>`

Fixes #47
Totktonada added a commit that referenced this issue Apr 1, 2022
The GraphQL specification explicitly forbids it:

 | Non-finite floating-point internal values (NaN and Infinity) cannot
 | be coerced to Float and must raise a field error.

http://spec.graphql.org/October2021/#sec-Float

Follows up #47
Totktonada added a commit that referenced this issue Apr 4, 2022
It is quite usual that a floating point number is encoded using JSON,
goes over HTTP, received on tarantool server, decoded from JSON and
passed as a variable into the GraphQL executor.

A number out of the [-10^14+1; 10^14-1] range is decoded into Lua as
cdata number[^1] to don't loss the precision. A JSON decoder don't know
that we intend to use this value as the floating point one and chooses
the conservative option: decode the value into cdata number to don't
loss the precision.

In GraphQL we know that it is actually the floating point value
(disregarding its representation in Lua). So it looks correct to accept
a cdata number as value of a Float variable.

The similar idea was expressed in [1] against tarantool itself: let it
accept a number without fractional part as a value suitable for the
`float` field type.

[1]: tarantool/tarantool#5933

[^1]: `cdata<int64_t>` or `cdata<uint64_t>`

Fixes #47
Totktonada added a commit that referenced this issue Apr 4, 2022
The GraphQL specification explicitly forbids it:

 | Non-finite floating-point internal values (NaN and Infinity) cannot
 | be coerced to Float and must raise a field error.

http://spec.graphql.org/October2021/#sec-Float

Follows up #47
Totktonada added a commit that referenced this issue Apr 4, 2022
It is quite usual that a floating point number is encoded using JSON,
goes over HTTP, received on tarantool server, decoded from JSON and
passed as a variable into the GraphQL executor.

A number out of the [-10^14+1; 10^14-1] range is decoded into Lua as
cdata number[^1] to don't loss the precision. A JSON decoder don't know
that we intend to use this value as the floating point one and chooses
the conservative option: decode the value into cdata number to don't
loss the precision.

In GraphQL we know that it is actually the floating point value
(disregarding its representation in Lua). So it looks correct to accept
a cdata number as value of a Float variable.

The similar idea was expressed in [1] against tarantool itself: let it
accept a number without fractional part as a value suitable for the
`float` field type.

[1]: tarantool/tarantool#5933

[^1]: `cdata<int64_t>` or `cdata<uint64_t>`

Fixes #47
Totktonada added a commit that referenced this issue Apr 4, 2022
The GraphQL specification explicitly forbids it:

 | Non-finite floating-point internal values (NaN and Infinity) cannot
 | be coerced to Float and must raise a field error.

http://spec.graphql.org/October2021/#sec-Float

Follows up #47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant