UPDATE: 现在问题似乎已在"global" Orion实例中得到纠正 .
我尝试更改实体的属性,但似乎没有想要的效果 . 我记得,相同的代码在2个月前运作良好 . 现在该怎么办?
我在"global" Orion Broker http://orion.lab.fi-ware.org:1026
中使用了float属性 test_1
实体 cie_test_1
. 我知道经纪人的意图是宣传不断变化的 Value 观 . 但是,似乎 Value 无法改变 . 交易细节如下 .
经纪人的版本信息是
{
"orion" : {
"version" : "0.19.0",
"uptime" : "0 d, 0 h, 2 m, 31 s",
"git_hash" : "1ad73b298cd261861203fbffb9c789f6ade2796d",
"compile_time" : "Wed Feb 11 13:00:19 CET 2015",
"compiled_by" : "fermin",
"compiled_in" : "centollo"
}
}
传输值请求
请求
POST http://orion.lab.fi-ware.org:1026/ngsi10/contextEntities/cie_test_1/attributes/test_1
Host: orion.lab.fi-ware.org:1026
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: application/json
Accept-Language: en-us,en;q=0.7,fi;q=0.3
Accept-Encoding: gzip, deflate
DNT: 0
Content-Type: application/json; charset=UTF-8
X-Auth-Token: <my auth token>
Content-Length: 14
Origin: null
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
有效载荷:
{"value":"50"}
NOTE: 试图设置 value
= 50
来自猎户座的回复
Access-Control-Allow-Headers: origin, content-type, X-Auth-Token, Tenant-ID
Access-Control-Allow-Methods: HEAD, POST, GET, OPTIONS, DELETE
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 61
Content-Type: application/json
Date: Fri, 13 Feb 2015 07:52:29 GMT
X-Powered-By: Express
有效载荷:
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
Firefox浏览器不喜欢这样的回复:
SyntaxError:JSON.parse:在JSON数据的第1行第14列的JSON数据之后出现意外的非空白字符
更好的JSON响应可能是:
{
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
}
来自猎户座的
值查询
查询
GET http://orion.lab.fi-ware.org:1026/ngsi10/contextEntities/cie_test_1
Host: orion.lab.fi-ware.org:1026
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: application/json
Accept-Language: en-us,en;q=0.7,fi;q=0.3
Accept-Encoding: gzip, deflate
DNT: 0
Content-Type: application/json
X-Auth-Token: <my auth token>
Origin: null
Connection: keep-alive
来自猎户座的回复
Access-Control-Allow-Headers: origin, content-type, X-Auth-Token, Tenant-ID
Access-Control-Allow-Methods: HEAD, POST, GET, OPTIONS, DELETE
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 289
Content-Type: application/json
Date: Fri, 13 Feb 2015 10:09:27 GMT
X-Powered-By: Express
有效载荷:
{
"Success: {
"contextElement" : {
"type" : "",
"isPattern" : "false",
"id" : "cie_test_1",
"attributes" : [
{
"name" : "test_1",
"type" : "float",
"value" : "10"
}
]
},
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
}
}
NOTE: value
仍然是 10
1 回答
此问题与service path functionality有关,特别是在0.19.0版本中引入了以下修复:
让我们考虑以下情况:实体文档存在于DB中,但它是使用0.19.0之前的Orion版本生成的,因此没有servicePath字段,即:
id = E1
type = T1
servicePath = [null]
attr.test_1 = 10
现在,Orion 0.19.0处理[E1,T1]上的updateContext APPEND(注意你问题中的POST有APPEND语义) . 这不会导致更新上一个实体文档,但会导致创建新的实体文档:
id = E1
type = T1
servicePath = "/"
attr.test_1 = 50
因此,现在我们在DB中的实体集合中有2个文档,几乎相等但不完全相等 . 实际上,如果你在[E1,T1]上使用带有服务路径“/”或没有servicePath的queryContext(含义上意味着“服务路径与查询无关”),你将在响应中得到两个,一个用10和其他与test_1属性相同 .
但是,基于GET的便捷操作与queryContext的工作方式不同(至少在当前的Orion版本中) . 便利性GET假定只有一个文档将被放入响应中,并且在这种模糊的情况下它采用较旧的文档(即,在DB中注释的修改日期较旧的文档) . 换句话说,test_1值为10的那个 .
解决方案是修复数据库,以便将2个实体文档合二为一(带有servicePath = "/") . 对于orion.lab.fi-ware.org(问题中的案例),FIWARE实验室的工作人员将在即将到来的日子里这样做 . 对于私有Orion实例,提供了merge_default_sp_dups.py脚本(请参阅database migration procedure for 0.19.0以获取更多信息) .
UPDATE: orion.lab.fi-ware.org数据库已修复 . 您不应再有问题中描述的更新问题 .