Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/types endpoints are inconsistently applying local #1707

Open
jason-fox opened this issue Nov 20, 2024 · 2 comments
Open

/types endpoints are inconsistently applying local #1707

jason-fox opened this issue Nov 20, 2024 · 2 comments
Assignees
Labels
bug Something isn't working Fixed - needs validation

Comments

@jason-fox
Copy link
Member

jason-fox commented Nov 20, 2024

Orion 1.6 -

I have a context broker and an IoT Agent.
context broker initially holds people, agri-parcels and buildings.

http://localhost:1026/ngsi-ld/v1/types returns:

{
    "id": "urn:ngsi-ld:EntityTypeList:04fed336-a679-11ef-b107-0242ac12010a",
    "type": "EntityTypeList",
    "typeList": [
        "https://schema.org/Person",
        "https://smartdatamodels.org/dataModel.Agrifood/AgriParcel",
        "https://smartdatamodels.org/dataModel.Building/Building"
    ]
}

When I add a REDIRECT registration to Farmer (which only holds Animals and run /types again. I get Animal added to the list:

{
    "id": "urn:ngsi-ld:EntityTypeList:04fed336-a679-11ef-b107-0242ac12010a",
    "type": "EntityTypeList",
    "typeList": [
        "https://schema.org/Person",
        "https://smartdatamodels.org/dataModel.Agrifood/AgriParcel",
        "https://smartdatamodels.org/dataModel.Agrifood/Animal",
        "https://smartdatamodels.org/dataModel.Building/Building"
    ]
}

So far so good. ✅

But if I run http://localhost:1026/ngsi-ld/v1/types?local=true I still get Animals in the list which is wrong. ❌

I have the reverse issue with an EXCLUSIVE registration. My context broker runs the following Registration:

curl --location 'http://localhost:1027/ngsi-ld/v1/csourceRegistrations/' \
--header 'Link: <http://context/ngsi-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json' \
--header 'Content-Type: application/json' \
--data '{
    "type": "ContextSourceRegistration",
    "information": [
        {
            "entities": [
                {
                    "type": "Animal",
                    "id": "urn:ngsi-ld:Animal:cow001"
                }
            ],
            "propertyNames": [
                "heartRate",
                "location"
            ]
        }
    ],
    "mode": "exclusive",
    "operations": [
        "retrieveOps"
    ],
    "endpoint": "http://devices",
    "contextSourceInfo": [
        {
            "key": "jsonldContext",
            "value": "http://context/ngsi-context.jsonld"
        }
    ]
}'

However when I run

curl --location 'http://localhost:1026/ngsi-ld/v1/types/Animal' \
--header 'Link: <http://context/ngsi-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json'

The new attributes of heartRate and location are not to be found ❌ - so this appears to be automatically applying local=true in this case.

The ETSI Spec is quite clear that local=true is required for /types:

6.3.18 Limiting Distributed Operations

The parameter described in this clause limits the execution of an operation to a local Context Source or
Context Broker (clause 5.5.13). It amends the matching Context Source Registrations behaviour as described
in clause 5.12, in the case of the HTTP binding in order to avoid cascading distributed operations (see
clause 4.3.6.4). For all operations the resources /entities/, /types/, /attributes/, /entityOperations/,
/temporal/entities/ and temporal/entityOperations/ (and their respective child resources) implementations
shall support the HTTP query parameter specified in Table 6.3.18-1.

@kzangeli
Copy link
Collaborator

First part done (local URI param for types discovery)

kzangeli added a commit that referenced this issue Dec 17, 2024
@kzangeli kzangeli self-assigned this Dec 17, 2024
@kzangeli kzangeli added bug Something isn't working Fixed - needs validation labels Dec 17, 2024
@kzangeli
Copy link
Collaborator

Second part done in #1722

kzangeli added a commit that referenced this issue Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Fixed - needs validation
Projects
None yet
Development

No branches or pull requests

2 participants