What is the Equals definition in current jsonquery

[lateapexearlyspeed]

Hi,

When I try function: uniq(), I wonder the definition of Equals because doc of uniq() not constraint type of arrary items.

From current https://jsonquerylang.org/ :

input:
[[1], 5, 3, 3, [1]]

query:
uniq()

output:
[[1], 5, 3, [1]]

[josdejong]

It's currently using strict equality:

jsonquery/src/functions.ts

Lines 217 to 219 in 09b7cb6

	uniq:
	() =>
	<T>(data: T[]) => [...new Set(data)],

It may be good indeed to either (a) throw an error in case of objects or arrays, or (b) compare by deep equality instead. Any thoughts?

[lateapexearlyspeed]

I think maybe it is better to have more standard definition for specific concept, deep equality for equality concept here is better maybe.

I think your json query is interesting query language so I am evaluating cross platform implementation, as your readme said. So it would be better to be more standard and platform-agnostic, not only for front-end technology concept, and have clear error output for mismatch between data type and query function.

BTW, can this json query language cover functionalities of other existing language like jmesPath ?

Thanks.

[josdejong]

Sorry for the late reply - I had taken a real holiday 😊.

I think maybe it is better to have more standard definition for specific concept, deep equality for equality concept here is better maybe.

We definitiely have to improve on the definitions. When I implemented a Python version of the query language, I also noticed some compatibility issues and missing definitions, so that really helped. We should refine the definitions more and more.

I think your json query is interesting query language so I am evaluating cross platform implementation, as your readme said. So it would be better to be more standard and platform-agnostic, not only for front-end technology concept, and have clear error output for mismatch between data type and query function.

Indeed being platform agnostic is a big feature to me, and the intermediary JSON representation is too. Whether the error messages are clear depends on the implementation (I think right now the JavaScript implementation gives better error messages than the Python implementation, but that can be improved upon).

BTW, can this json query language cover functionalities of other existing language like jmesPath ?

Yes it can, though currently there is no 100% coverage of the functionality offered by JMESPath. I think it comes close though and mostly involves defining some more functions like ends_with and merge. I may be overlooking some of the features of JMESPath though, if so, please let me know.

[lateapexearlyspeed]

We definitiely have to improve on the definitions

Yes, hope this can be improved, thanks.

have clear error output for mismatch between data type and query function

Sorry I mean having standard document to specify what if there is mismatch between input data type and query function, for example:

input: "abc"
query: sum()

I have not found out related document about this kind of mismatch in JsonQuery, so I checked similar case description from JMESPath and for now decide to return null for mismatch query, rather than throwing error, so that outer query part can continue.

[josdejong]

I think we have to extend the compile.test.json suite with a way to verify that certain combinations of input and query throws an error, currently there is no way to test whether an error is thrown. I'll think that through and start adding cases like yours above, very good point!

There is no relation with JMESPath, it may be better to look at whether https://jsonquerylang.org/ throws an error or returns null, and when you see cases that do not make sense, raise an issue here so we can unify and define the behavior in the test suites.

As for the case "input": "abce", "query": "sum()", I think this should throw an exception.

[josdejong]

@lateapexearlyspeed I've created two PR's that will adress this topic:

• feat: deep equal support #20
• feat: add test cases for handling empty arrays and non-array input in functions #21

Your feedback on this would be very welcome!