Query Language for advanced Queries

[jmcanterafonseca]

What query language should be used in API v2 for advanced queries?

Different languages have been considered so far:

https://docs.google.com/document/d/11bhW22FttBotCDhmJKs3-Ju_j8wGvBCYNTdMKlj72K4/edit

MQL seems to be a good candidate but the main issue are OR clauses and the ambiguity of some expressions in the language:

http://mql.freebaseapps.com/ch03.html http://mql.freebaseapps.com/ch04.html

We might be inspired by MQL but some improvements might be suggested.

[fgalan]

Language proposal to take into account: https://github.com/jayway/JsonPath (proposed by Tobias Jacobs)

[fgalan]

One aspect to take into account when deciding the right language is support in the main programming languages (C++, Java, etc.). It wouldn't be a good idea to chose a language that from a theoretical point of view is perfect, but lacks of mature libraries that help to implement it.

[fgalan]

Another language that has been mentioned (from MPEG): http://www.mpegqueryformat.org/

[tobiasjacobs]

Maybe we should come to a common understanding of what the function of the query language in NGSI should be.

The semantics of the XPATH restriction in NGSI 1.0 is that the XPATH expression is applied to the query response (or notification) before the response is returned to the client.

• The advantages of this approach are (a) simplicity and (b) the absence of any assumption on how the NGSI system generates the response.
• A disadvantage is that it is potentially inefficient for the NGSI system to first generate the full unrestricted answer and only then apply the XPATH expression.

In my opinion the new restriction language should satisfy at least advantage (b). So what I propose is that it should again work like first the unrestricted query is generated and then the restriction is applied.

Of course, not every NGSI system will need to first fully generate the unrestricted response. For example, NGSI systems based on a central database can potentially include the restriction already in the database query. But from the user point of view the result should be AS IF the restriction is applied to the unrestricted response.

Thus, in my opinion we should choose a query language that can be applied directly to the query response / notification JSON documents, without any assumptions on how these JSON documents are stored or generated.

[fgalan]

Out of the scope of NGSIv2, althouth it is a good idea that could (potentially) be included in a later version of the API (v2.1) in a backward compatible way.

CC: @jmcanterafonseca

[fgalan]

Maybe useful (a text to BSON mongo filter translator): https://github.com/FIWARE/context.Orion-LD/pull/165