You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JsonPath language isn't standardized. When SQL accommodated it, they actually formally specified the language, however in a different flavor. Example differences:
array ranges are indexed as $[1 to 2] instead of $[1:2]
properties are quoted as $."property with space" instead of $['property with space']
separate strict and lax modes: in strict mode, non-existent property or out-of-bounds array index throw, in lax mode they return null.
I'm not deeply familiar with the SQL's nuances, there might be a couple more differences. We're implementing JsonPath support in an SQL engine. My question is have you ever considered supporting the SQL flavor? Would you accept PRs adding support for them, provided that the old syntax is unaffected and the SQL way will be an alternative syntax? So far this seems possible. Or to provide a configuration setting to pick the flavor?
The text was updated successfully, but these errors were encountered:
You're right. There is no standard JsonPath so far. And you can find comparison for most JsonPath implementation here: https://github.com/cburgmer/json-path-comparison
I'm not sure whether most of JsonSurfer users need SQL flavor syntax. I could add it as an option, if there were enough vote for it. For now I would suggest you make a fork first to implement different JsonPathCompiler for the SQL syntax
The JsonPath language isn't standardized. When SQL accommodated it, they actually formally specified the language, however in a different flavor. Example differences:
$[1 to 2]
instead of$[1:2]
$."property with space"
instead of$['property with space']
I'm not deeply familiar with the SQL's nuances, there might be a couple more differences. We're implementing JsonPath support in an SQL engine. My question is have you ever considered supporting the SQL flavor? Would you accept PRs adding support for them, provided that the old syntax is unaffected and the SQL way will be an alternative syntax? So far this seems possible. Or to provide a configuration setting to pick the flavor?
The text was updated successfully, but these errors were encountered: