Closed briangwaltney closed 5 months ago
Thanks for this! Just curious.. Was it intended to have the value for named_args be string, even when the type is integer? Example: this fails to retrieve data.. "named_args": [ { "name": "groupId", "value": { "type": "integer", "value": 1 } }...
But this retrieves it just fine: "named_args": [ { "name": "groupId", "value": { "type": "integer", "value": "1" } }...
I noticed that also for integers. With the current api, integers must be turned into strings, but floats must be real float numbers.
@briangwaltney @AmithabK this is because the some languages (javascript for instance), will parse json number into JS numbers, which are floats under the hood. For big numbers that can lead to precision loss, and they should instead be parsed into BigInt from the string representing them.
Thanks for the explanation. Makes sense to me!
lgtm
The documentation on bound parameters using the HTTP client was lacking and the blog article about this api was outdated.
I added examples for named and unnamed parameters to the reference page and added a link to those examples to the Quickstart page.