JSON: function "query"

[ralfhandl]

Resolves https://issues.oasis-open.org/browse/ODATA-1336

Check which syntax elements are supported by which implementation

• Node.js implementation: https://www.npmjs.com/package/jsonpath (all)
• Java implementation: https://github.com/json-path/JsonPath (all)
• SAP HANA (root, member, single index, wildcard, index range)
• Microsoft SQL Server (root, member, single index)
• Google BigQuery (root, member, single index)

[HeikoTheissen]

The proposed OData function JSON.value can instead be implemented with the SQL function JSON_QUERY, which returns a stringified JSON

But if JSON.value occurs in a common expression, SQL cannot parse the stringified JSON for each row. Therefore

$filter=resume/JSON.value('$.birthYear') gt ReceivedYear sub 18

(to find applications by under-age candidates) would be converted into

where JSON_VALUE(Stream, '$.birthYear') >= "ReceivedYear" - 18

which makes sense if the implicit casting rules for OData common expressions are the same as for SQL.

But

$compute=resume/JSON.value('$.birthYear') as BirthYear

could then not be converted into SQL without parsing JSON, since BirthYear must be numeric.

Perhaps it is better to have three functions:

• JSON.value returns the string computed by JSON_VALUE
• JSON.query returns a JSON.JSON as computed by JSON_QUERY
• JSON.parsedquery returns a JSON.JSON for JSON objects but a primitive value like Edm.String or Edm.Boolean otherwise. It does so by parsing the stringified JSON returned by JSON_QUERY. This could be used in the $compute example above, but probably not be part of a bigger common expression.

Doubts about $compute

[HeikoTheissen]

TC 2024-04-03 agrees to have return-type-specific functions JSON.stringValue, JSON.intValue etc.

[mikepizzo]

Alternative: single JSON_QUERY function with optional 3rd parameter that specified return type. The type of this function would have to be Edm.Untyped; may still have to cast to compose in expression.

Other alternative: have different functions for each type to be returned, thus avoiding the cast.

It would be more extensible to pass a type name to return as, but then the return type of the function would not be strongly typed (it would have to be Edm.Untyped) so it would have to be cast in an expression/annotated in a response.

If there are only a handful of types that may be returned, we can define separate functions for each return type which would improve usability.

[sthagen]

LGTM.