Request: Implement temporal/entityOperations/query and entityOperations/query about python-ngsild-client

[fbattello]

For the moment I test mostly against Orion-LD.
So your feedback is precious.
I will follow your suggestion. I think to add it at the Client level, by providing an extra argument at the init time.
Something like :

client = Client(use_alt_query_endpoints=True)

[fbattello]

Agree.
Eventually it's the best way to deal with the 2 verbs separately, as it implies many differences.
The lib also has a count() method that will be impacted, playing a role in pagination.
So, to sum up : give up the client level config (considered at the beginning) that's not needed any more.
The query() method remains and uses the GET verb.
A new query_post() method will handle the POST verb and will accept a dict to hold the whole JSON-LD Query data structure.

[fbattello]

Done and published in v0.4.2.
Documentation still to be updated.
I haven't been able to test the temporal/entityOperation/query because either not supported by my Orion-LD version or not hit the good endpoint in Mintaka.
For convenience, query methods have the same name.
The alternative (post query) methods can be found in client.alt to query entities, and client.temporal.alt to query temporal.

Example :

from ngsildclient import Entity, Client, iso8601
farm = Entity("Farm", "Farm001").prop("fillingLevel", 0.8, observedat=iso8601.utcnow())
client = Client(port=8026, port_temporal=8027)
query = {"type": "Query", "entities": [{"type": "Farm"}], "q": "fillingLevel>0.7"}
client.alt.query(query)

I close this ticket at this point.
Please open new issue if needed, especially on the temporal part.

[fbattello]

Hi,

Both the "Query Entities" and the "Query Temporal Evolution of Entities" operations are supported, but rely on other endpoints.

Given a client: Client instance, you can query respectively by using these 2 sets of methods :

• client.query(), client.query_head(), client.query_handle(), client.query_generator()
• client.temporal.query(), client.temporal.query_head(), client.temporal.query_handle(), client.temporal.query_generator()

The endpoints you mention are presented as "alternative" endpoints to provide the same features by using POST requests instead of GET requests, that could be problematic when dealing with huge query strings.

Do you need to specify huge query strings ? If not, the actual implementation will do the exact same job.

[Blobonat]

Do you need to specify huge query strings ? If not, the actual implementation will do the exact same job.

Yeah, that's my use case. I want to retrieve a large number of entities in 1 request resulting in a long query string, that could be problematic with a GET request.

[fbattello]

Ok.
On my side I don't see the value in supporting these query features on 2 different sets of endpoints.
As the one you mention is the one solution fits all, I propose to simply give up the existing "GET-dedicated-endpoints" and implement only the set of "POST-dedicated-endpoints".
Do you feel any need to keep the old ones ?

[Blobonat]

From the theoretical point of view I do not see a need to keep the GET endpoints. With the current existing Context Brokers I experienced that the POST endpoints still have some differences in their implementations. This could break the Python client in existing applications. I suggest to integrate both endpoints and later get rid of the GET endpoints.

[Blobonat]

The client level configuration is a great idea.

[fbattello]

It's more complicated than I had expected at first sight.

The content sent to the broker is completely different when using the POST method.
It's not any more just a string built from many parts : a slice of query string, a slice of geoquery string, ...
It's a JSON-LD structure as described in the ETSI specification : Table 5.2.23-1: Query data type definition

2 solutions are possible ;

• map each existing argument to build the whole JSON-LD from each part => some input args become dict instead of string
• add a new ngsild_query arg that holds the whole JSON-LD => ignore other args

def query(self, type: str = None, q: str = None, gq: Union[str, dict] = None) -> List[Entity]:
    ...

def query(self, type: str = None, q: str = None, gq: str = None, ngsild_query: dict = None) -> List[Entity]:
    ...

Which of these 2 implementations you would like to work with ?

[Blobonat]

Haven't thought of the problems with the different request structure... I think using just the q parameter doesn't use the full potential of the POST request. Depending on the concrete CB implementation, the EntityInfo (in later specs called EntitiySelector) can help to boost the performance of the query. Leaving the entities part out of the POST request would work theoretically, but may be inconvenient for certain use cases.

Having a second thought, it actually might be better to implement the POST and GET endpoints separately.

[Blobonat]

I will test the client with the temporal endpoint within the next few days and will provide feedback if necessary.