How to obtain id without additional attrs

[jason-fox]

http://{{orion}}/ngsi-ld/v1/entities/?type=Shelf&options=keyValues&q=locatedIn=="urn:ngsi-ld:Building:store001"

Works fine - I get the full entity.

http://{{orion}}/ngsi-ld/v1/entities/?type=Shelf&options=keyValues&q=locatedIn=="urn:ngsi-ld:Building:store001"&attrs=locatedIn

Works fine - I get id, type and locatedIn.

How should I get back just id and type?

• attrs=id,type returns an empty array (presumably because they aren't real attributes)
• attrs=somethingElse returns an empty array (because the attr doesn't exist)

So how should I just get the id and type? Why does attrs=[blank] not work?

The assumption is that attrs should be a list of attrs, and an empty list should be valid.

This functionality is justified when dealing with uni-directional relationships. In the case of relationships I may want to use q across a type - since the relationship may not be reciprocated in the other entity. attrs= would make sense to me as the right syntax in that case.

For example what if I have the locatedIn Shelf ▶️ Building relationship only. How can make a request to return give me all the shelves in a building?

At the moment any request would need to return an unnecessary extra attr. Similarly a subscription would need to return extra stuff just to be thrown away.

[jmcanterafonseca]

why do you need a new query parameter attr. Wouldn't just suffice with allowing attrs to be just an empty list?

[jason-fox]

I agree. That was my idea as well, but at the moment attrs=[blank] returns nothing rather than an array (type, id) without extra attrs. I think the functionality needs amending.

Edit: I noticed and amended my typo above. For clarification I mean attrs throughout.

[jmcanterafonseca]

And the spec would need an update to allow empty attr list both in queries and subscriptions

El jueves, 19 de septiembre de 2019, Jason Fox [email protected] escribió:

I agree. That was my idea as well, but at the moment attrs=[blank] returns nothing rather than an array without extra attrs. I think the functionality needs updating.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FIWARE/context.Orion-LD/issues/232?email_source=notifications&email_token=AAFJT7XF2Y7AIM6GJWZIAWLQKMRQXA5CNFSM4IYALF2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7CPI6Q#issuecomment-533001338, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFJT7WRHFFAW62ACK2LF7TQKMRQXANCNFSM4IYALF2A .

[jason-fox]

Current behaviour ( dc7d4a7e ) means that placing a non-existent attribute will ensure the list is empty e.g. :

• http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Shelf:unit001/?options=keyValue&attrs=none

id and type only since none is not an attribute

• http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Shelf:unit001/?options=keyValue&attrs=amne

id and type only since amne is not an attribute

• http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Shelf:unit001/?options=keyValue&attrs=name

id and type and name

• http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Shelf:unit001/?options=keyValue&attrs=name,anme

id and type and name since amne is not an attribute

[jason-fox]

• http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Shelf:unit001/?options=keyValue&attr=

Still returns the whole entity

[michaeI-s]

At the moment any request would need to return an unnecessary extra attr. Similarly a subscription would need to return extra stuff just to be thrown away.

Exactly. There are situations when you only want a list of IDs of existing entities in the broker. But currently you are forced to use the attrs parameter with at least one 'real' attribute just to reduce the response payload to a minimum.

[zigc]

This issue is still present in "orionld version": "post-v1.1.0".

Can you provide an update on the status of the issue discussed? We are still encountering it and would like to know what progress has been made in resolving it.

[kzangeli]

This is not an issue with orion-ld, but an issue with the ngsi-ld API spec. We'll discuss this in the etsi isg cim meetings, where the API is defined

[Jxlle]

Is there any roadmap or progress on this issue? For our use-case, to be able to just get the id and type would also be interesting.

[kzangeli]

Sorry, nothing so far. Simply because I forgot about it. I'll send a line about this to my colleagues in ETSI ISG CIM right now (we have a ckype chat group where we often discuss the API)

[kzangeli]

We're discussing it now. I'm proposing to add a URL param "projection". We'll see how it goes ... :)

[kzangeli]

Ah, of course, I should tell you guys that Orion-LD already implements a URL param for this: "onlyIds=true". Right now it returns an array of only Entity IDs, but, this will change. I didn't get my way in ETSI ISG CIM and the response will be a bit more complex in the future, once I change the implementation to follow the spec (I implemented this before we added it to the API spec). It doesn't give you the entity type, only the IDs. But, might serve you until we straighten this "projection" thing out and I can implement it.

[Jxlle]

Hi @kzangeli

Thanks for the suggestion! I tried it with the following uri: .../ngsi-ld/v1/entities/?type=Transport&onlyIds=true. However, it returned the following:

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/BadRequestData",
    "title": "Unknown URI parameter",
    "detail": "onlyIds"
}

[kzangeli]

ok, sorry about that. It is implemented, just, you have to start the broker in "experimental mode". Don't let the name scare you, it is quite tested. It was experimental, but that was a long time ago.

This is the new implementation, pending performance tests to be made default mode. It uses the new mongoc driver instead of the old one (mongocpp) that was deprecated like 6-7 years ago.

Env var is: export ORIONLD_EXPERIMENTAL=TRUE

[jason-fox]

Bump. According to the 1.8.1 NGSI-LD Specification (just published March 2024) ,reduction to id only can be obtained using the pick and omit attributes. For example:

curl -L 'http://localhost:1026/ngsi-ld/v1/entities/?type=Building&pick=id' \
-H 'Link: <http://context/ngsi-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json'

Should return:

[
    {
        "id": "urn:ngsi-ld:Building:farm001"
    },
    {
        "id": "urn:ngsi-ld:Building:barn002"
    },
    {
        "id": "urn:ngsi-ld:Building:tower003"
    },
    {
        "id": "urn:ngsi-ld:Building:farm002"
    }
]

However, since the implementations usually lag the specification (and the spec is only a week old at the time of writing), Orion-LD currently returns:

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/BadRequestData",
    "title": "Unknown URI parameter",
    "detail": "pick"
}