search

orchestracities / ngsi-timeseries-api

QuantumLeap: a FIWARE Generic Enabler to support the usage of NGSIv2 (and NGSI-LD experimentally) data in time-series databases
https://quantumleap.rtfd.io/
MIT License
38 stars 49 forks source link

Fiware-ServicePath semantics #757

Closed pkel-kn closed 4 months ago

pkel-kn commented 4 months ago

I have a couple of entities in Fiware-ServicePath: /xyz. The requests

GET /v2/entities

and

GET /v2/entities
Fiware-ServicePath: /#

do not return any entities. The request

GET /v2/entities
Fiware-ServicePath: /xyz

does.

I expect the former two requests to include the entities of the latter request as it is the case with Orion.

The QuantumLeap OpenAPI spec says the service path semantics are like in Orion, so I consider this a bug of QuantumLeap.

My QuantumLeap version is 0.8.2.

c0c0n3 commented 4 months ago

@pkel-kn thank you for taking the time to report this, much appreciated.

First off, and slightly off topic, keep in mind that, for better or for worse, Quantum Leap doesn't behave exactly the same as Orion. Truth be told, I don't think there's ever been a proper (formal) NGSI service path spec with unambiguous semantics---not in Quantum Leap, not in Orion or any other FIWARE docs I'm aware of. (LD partially fixes this though). So the spec is the implementation and like I said Quantum Leap has a slightly different interpretation of "service path" than Orion does. I don't think there's any easy way to change this in Quantum Leap without breaking or rewriting quite a bit of stuff.

Re: your specific case, to the /v2/entities endpoint

  1. /# has no special meaning. It's just a literal service path just like /xyz. If you happen to have an entity under a service path of /#, Quantum Leap should return it. I don't think this feature is actually any useful so you should most likely ignore it and never use /# as a literal service path.
  2. Any service path string matches all the entities whose service path begins with that string. (https://github.com/orchestracities/ngsi-timeseries-api/blob/master/src/translators/sql_translator.py#L817)

(2) should work for CrateDB, but I'm not sure what happens with a Timescale backend. Which one are you using? If CrateDB is your backend, then adding a service path of / should return all the entity ids. Also it could be a bug in 0.8.2. Unfortunately we have no manpower to support old releases, so you should try upgrading to the latest Quantum Leap version if you can.

pkel-kn commented 4 months ago

Thank you for looking into this!

Part of my confusion comes from QuantumLeap's documentation, current version. It says that QL service path corresponds to Orion service path by linking to Orion's documentation. I think future users will appreciate if you update this documentation to include what you describe above.

I'm using the Postgres Backend.

I see that the release notes for QuantumLeap 1 mentions some work on service paths. Unfortunately I cannot easily upgrade QuantumLeap. My conclusion is to stay away from ServicePath, at least for now.

c0c0n3 commented 4 months ago

Thank you for looking into this!

Well, thank you for bringing this up!

my confusion comes from QuantumLeap's documentation

I've just looked at it, the documentation is misleading, to say the least, sorry about that :-)

I think future users will appreciate if you update this documentation

Agree, I've opened #758 about it

My conclusion is to stay away from ServicePath

Given your current setup, that's probably the most sensible thing to do for now