具有已创建类型的实体的上下文代理,在没有类型的实体创建中响应正常,但在列出实体时不显示

Context Broker with an entity with type created, response ok in an entity creation without type, but is not show when entities are listed

当使用类型创建实体,然后创建具有相同 ID 但类型为空的实体时,contextbroker 响应正常,但未创建实体。

但如果创建顺序相反,首先是具有空 id 的实体,然后是具有 a 类型的实体,上下文代理响应为 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

虽然看起来很奇怪,但脚本 1 根据 CB 定义的功能正常运行。第二个 POST 中 type = "" 的含义不会导致 "entity with id firstID and without type",而是 "any entity with id firstID no matter its type"(参见 context broker manual)。因此,假设已经有一个实体与 "any entity with id firstID no matter its type" 匹配(即在第一个 POST 中创建的实体,其 ID 为 firstID 且类型为 firstType),请求不会被解释为创建而是更新(来自 Orion 用户手册:"current Orion Context Broker version interprets APPEND [the POST on that URL equals to an APPEND updateContext] as UPDATE if the entity already exists")。

有一种表达方式 "entity without type",使用 !exists 过滤器。如果在 script1

中更改以下第 35 行
curl http://$HOST:1026/v1/contextEntities \

这个

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

你将在最后创建 2 个实体(一个有类型,另一个没有)。