2

当一个实体被创建一个类型，然后，一个具有相同id但类型为空的实体被创建，contextbroker响应ok，但实体没有被创建。

但是如果创建的顺序相反，首先是具有空 id 的实体，然后是具有 aa 类型的实体，上下文代理响应为 ok 并列出实体。

执行案例1的脚本

#/bin/bash
HOST=localhost
SERVICE=Service123
SUBSERVICE=/Subservice123
#Create an entity with id and type
CREATE=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X POST \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
    -d '
        {
          "id": "firstID",
          "type": "firstType",
          "attributes": []
        }')
#List the entities
LIST=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X GET \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
)
echo $CREATE
echo "**********************"
echo $LIST
#Create an entity with the same ID but different type
CREATE=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X POST \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
    -d '
        {
          "id": "firstID",
          "type": "",
          "attributes": []
        }')
#List the entityies
LIST=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X GET \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
)
echo
echo "Second Iteration"
echo
echo $CREATE
echo "**********************"
echo $LIST

执行案例 2 的脚本

#/bin/bash
HOST=localhost
SERVICE=Service1234
SUBSERVICE=/Subservice1234
#Create an entity with id and type
CREATE=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X POST \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
    -d '
        {
          "id": "firstID",
          "type": "",
          "attributes": []
        }')
#List the entities
LIST=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X GET \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
)
echo $CREATE
echo "**********************"
echo $LIST
#Create an entity with the same ID but different type
CREATE=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X POST \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
    -d '
        {
          "id": "firstID",
          "type": "fistType",
          "attributes": []
        }')
#List the entityies
LIST=$(\
curl http://$HOST:1026/v1/contextEntities \
    -s \
    -X GET \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Fiware-Service: $SERVICE" \
    -H "Fiware-ServicePath: $SUBSERVICE" \
)
echo
echo "Second Iteration"
echo
echo $CREATE
echo "**********************"
echo $LIST
4

1 回答 1

0

虽然看起来很奇怪，但脚本 1 根据 CB 定义的功能正常工作。type = "" 在第二个 POST 中的含义不是“具有 id firstID 且没有类型的实体”，而是“任何具有 id firstID 的实体，无论其类型如何”（参见上下文代理手册）。因此，假设已经有一个实体匹配“任何具有 id firstID 的实体，无论其类型如何”（即在第一个 POST 中创建的，具有 id firstID 和类型 firstType 的实体），请求不会被解释为创建，而是被解释为更新（来自 Orion 用户手册：“如果实体已经存在，则当前 Orion Context Broker 版本将 APPEND [该 URL 上的 POST 等于 APPEND updateContext] 解释为 UPDATE”）。

有一种表示“没有类型的实体”的方法，使用 !exists 过滤器。如果您在 script1 中更改以下第 35 行

curl http://$HOST:1026/v1/contextEntities \

对于这个

curl http://$HOST:1026/v1/contextEntities?!exist=entity::type \

您将在最后创建 2 个实体（一个有类型，另一个没有它）。

于 2015-01-16T12:16:12.867 回答