Details
-
Type: Monitor
-
Status: Closed
-
Priority: Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:
Description
Created question in FIWARE Q/A platform on 29-10-2018 at 12:10
Please, ANSWER this question AT https://stackoverflow.com/questions/53044149/how-to-avoid-registrations-result-when-query-the-entities-filtered-by-a-relation
Question:
How to avoid registrations result when query the entities filtered by a relationship
Description:
I've deployed the iot stack with docker. These are the used containers:
fiware/orion:2.0.0
fiware/iotagent-json:1.8.0
[other containers not involved in the issue ...]
Documentation consulted:
http://fiware.github.io/specifications/ngsiv2/stable/
Step 1: I've registered the following entities on the Orion context broker:
curl -X POST \
http://localhost:1026/v2/op/update/ \
-H 'Content-Type: application/json' \
-H 'fiware-service: test' \
-H 'fiware-servicepath: /' \
-d '{
"actionType": "append",
"entities": [{
"type": "Area",
"id": "first:Area:001",
"name":
}, {
"type": "Area",
"id": "second:Area:002",
"name":
}]
}'
Step 2: I've registered the following device related with the Area first:Area:001 on the IoT agent:
curl -X POST \
http://localhost:4041/iot/devices \
-H 'Content-Type: application/json' \
-H 'fiware-service: test' \
-H 'fiware-servicepath: /' \
-d '{
"devices": [{
"device_id": "device001",
"entity_name": "first:Area:001:IoTDevice:001",
"entity_type": "IoTDevice",
"transport": "HTTP",
"protocol": "IoTA-JSON",
"endpoint": "http://context-producer:3000/iot/iot-device/device001",
"commands": [
],
"attributes": [
],
"static_attributes": [
,
{ "name": "name", "type": "Text", "value": "IoT Device 001" } ]
}]
}'
Request 1: When you perform step 2, registration-type entities are automatically generated on the Orion context broker
curl -X GET \
http://localhost:1026/v2/registrations/ \
-H 'fiware-service: test' \
-H 'fiware-servicepath: /'
Result:
[
{
"id": "5bd6dbb2bef7081490c96eb2",
"dataProvided": {
"entities": [
],
"attrs": [
"ping"
]
},
"provider": {
"http":
,
"supportedForwardingMode": "all",
"legacyForwarding": true
},
"status": "active"
}
]
Test 1: Getting the IoTDevice-type entities related with the Area first:Area:001
curl -X GET \
'http://localhost:1026/v2/entities?options=keyValues&q=refArea==first:Area:001' \
-H 'fiware-service: test' \
-H 'fiware-servicepath: /'
OK Expected Result:
[
{ "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice", "TimeInstant": " ", "count": 0, "name": "IoT Device 001", "ping_info": " ", "ping_status": "UNKNOWN", "refArea": "first:Area:001", "ping": "" }]
Test 2: Getting the IoTDevice-type entities related with the Area second:Area:001
curl -X GET \
'http://localhost:1026/v2/entities?options=keyValues&q=refArea==second:Area:001' \
-H 'fiware-service: test' \
-H 'fiware-servicepath: /'
ERROR unexpected Result:
[
{ "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice", "ping": "" }]
The expected result was [ ] or empty but the query returned results that seem to come from the registration-type entities. This only happens if devices with attributes of type command are inserted. For example, the ping command.
So, How can this be avoided?
Activity
Field | Original Value | New Value |
---|---|---|
Component/s | FIWARE-TECH-HELP [ 10278 ] |
HD-Enabler | Orion [ 10875 ] | |
Description |
Created question in FIWARE Q/A platform on 29-10-2018 at 12:10 {color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/53044149/how-to-avoid-registrations-result-when-query-the-entities-filtered-by-a-relation +Question:+ How to avoid registrations result when query the entities filtered by a relationship +Description:+ I've deployed the iot stack with docker. These are the used containers: fiware/orion:2.0.0 fiware/iotagent-json:1.8.0 [other containers not involved in the issue ...] Documentation consulted: http://fiware.github.io/specifications/ngsiv2/stable/ Step 1: I've registered the following entities on the Orion context broker: curl -X POST \ http://localhost:1026/v2/op/update/ \ -H 'Content-Type: application/json' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' \ -d '{ "actionType": "append", "entities": [{ "type": "Area", "id": "first:Area:001", "name": { "type": "Text", "value": "First area" } }, { "type": "Area", "id": "second:Area:002", "name": { "type": "Text", "value": "Second area" } }] }' Step 2: I've registered the following device related with the Area first:Area:001 on the IoT agent: curl -X POST \ http://localhost:4041/iot/devices \ -H 'Content-Type: application/json' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' \ -d '{ "devices": [{ "device_id": "device001", "entity_name": "first:Area:001:IoTDevice:001", "entity_type": "IoTDevice", "transport": "HTTP", "protocol": "IoTA-JSON", "endpoint": "http://context-producer:3000/iot/iot-device/device001", "commands": [{ "name": "ping", "type": "command" }], "attributes": [{ "object_id": "c", "name": "count", "type": "Number" }], "static_attributes": [{ "name": "refArea", "type": "Relationship", "value": "first:Area:001" }, { "name": "name", "type": "Text", "value": "IoT Device 001" } ] }] }' Request 1: When you perform step 2, registration-type entities are automatically generated on the Orion context broker curl -X GET \ http://localhost:1026/v2/registrations/ \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' Result: [ { "id": "5bd6dbb2bef7081490c96eb2", "dataProvided": { "entities": [ { "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice" } ], "attrs": [ "ping" ] }, "provider": { "http": { "url": "http://iotagent-json:4041" }, "supportedForwardingMode": "all", "legacyForwarding": true }, "status": "active" } ] Test 1: Getting the IoTDevice-type entities related with the Area first:Area:001 curl -X GET \ 'http://localhost:1026/v2/entities?options=keyValues&q=refArea==first:Area:001' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' OK Expected Result: [ { "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice", "TimeInstant": " ", "count": 0, "name": "IoT Device 001", "ping_info": " ", "ping_status": "UNKNOWN", "refArea": "first:Area:001", "ping": "" } ] Test 2: Getting the IoTDevice-type entities related with the Area second:Area:001 curl -X GET \ 'http://localhost:1026/v2/entities?options=keyValues&q=refArea==second:Area:001' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' ERROR unexpected Result: [ { "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice", "ping": "" } ] The expected result was [ ] or empty but the query returned results that seem to come from the registration-type entities. This only happens if devices with attributes of type command are inserted. For example, the ping command. So, How can this be avoided? |
Created question in FIWARE Q/A platform on 29-10-2018 at 12:10
{color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/53044149/how-to-avoid-registrations-result-when-query-the-entities-filtered-by-a-relation +Question:+ How to avoid registrations result when query the entities filtered by a relationship +Description:+ I've deployed the iot stack with docker. These are the used containers: fiware/orion:2.0.0 fiware/iotagent-json:1.8.0 [other containers not involved in the issue ...] Documentation consulted: http://fiware.github.io/specifications/ngsiv2/stable/ Step 1: I've registered the following entities on the Orion context broker: curl -X POST \ http://localhost:1026/v2/op/update/ \ -H 'Content-Type: application/json' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' \ -d '{ "actionType": "append", "entities": [{ "type": "Area", "id": "first:Area:001", "name": { "type": "Text", "value": "First area" } }, { "type": "Area", "id": "second:Area:002", "name": { "type": "Text", "value": "Second area" } }] }' Step 2: I've registered the following device related with the Area first:Area:001 on the IoT agent: curl -X POST \ http://localhost:4041/iot/devices \ -H 'Content-Type: application/json' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' \ -d '{ "devices": [{ "device_id": "device001", "entity_name": "first:Area:001:IoTDevice:001", "entity_type": "IoTDevice", "transport": "HTTP", "protocol": "IoTA-JSON", "endpoint": "http://context-producer:3000/iot/iot-device/device001", "commands": [{ "name": "ping", "type": "command" }], "attributes": [{ "object_id": "c", "name": "count", "type": "Number" }], "static_attributes": [{ "name": "refArea", "type": "Relationship", "value": "first:Area:001" }, { "name": "name", "type": "Text", "value": "IoT Device 001" } ] }] }' Request 1: When you perform step 2, registration-type entities are automatically generated on the Orion context broker curl -X GET \ http://localhost:1026/v2/registrations/ \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' Result: [ { "id": "5bd6dbb2bef7081490c96eb2", "dataProvided": { "entities": [ { "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice" } ], "attrs": [ "ping" ] }, "provider": { "http": { "url": "http://iotagent-json:4041" }, "supportedForwardingMode": "all", "legacyForwarding": true }, "status": "active" } ] Test 1: Getting the IoTDevice-type entities related with the Area first:Area:001 curl -X GET \ 'http://localhost:1026/v2/entities?options=keyValues&q=refArea==first:Area:001' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' OK Expected Result: [ { "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice", "TimeInstant": " ", "count": 0, "name": "IoT Device 001", "ping_info": " ", "ping_status": "UNKNOWN", "refArea": "first:Area:001", "ping": "" } ] Test 2: Getting the IoTDevice-type entities related with the Area second:Area:001 curl -X GET \ 'http://localhost:1026/v2/entities?options=keyValues&q=refArea==second:Area:001' \ -H 'fiware-service: test' \ -H 'fiware-servicepath: /' ERROR unexpected Result: [ { "id": "first:Area:001:IoTDevice:001", "type": "IoTDevice", "ping": "" } ] The expected result was [ ] or empty but the query returned results that seem to come from the registration-type entities. This only happens if devices with attributes of type command are inserted. For example, the ping command. So, How can this be avoided? |
Assignee | Jose Manuel Cantera [ jmcantera ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | Answered [ 10104 ] |
Resolution | Done [ 10000 ] | |
Status | Answered [ 10104 ] | Closed [ 6 ] |
Fix Version/s | 2021 [ 12600 ] |
Transition | Time In Source Status | Execution Times | Last Executer | Last Execution Date | |||||
---|---|---|---|---|---|---|---|---|---|
|
6d 18h | 1 | Backlog Manager | 05/Nov/18 9:06 AM | |||||
|
1d 2h 59m | 1 | Backlog Manager | 06/Nov/18 12:05 PM | |||||
|
1d | 1 | Backlog Manager | 07/Nov/18 12:06 PM |
2018-10-29 15:06|CREATED monitor | # answers= 0, accepted answer= False