Store structured context values for attributes using FIWARE Orion Context Broker and CYGNUS MongoDB Sink?
up vote
2
down vote
favorite
Background
I'm using the following Generic Enablers in a specific application that I am building over FIWARE:
- Orion Context Broker
- CYGNUS NGSI
- STH-Comet
Also, I'm using MongoDB database, in order to persist all raw historical data received by Cygnus. To do so, I've configured a MongoDB Sink in CYGNUS, as indicated here.
Then I have a context entity, for which some attributes has structured values, instead of simple types like string. For example: a collection or a dictionary.
Fortunately this is possible!! Check the Orion's official documentation for details.
Apart from simple values such as 22.5 or "yellow", you can use complex structures as attribute values. In particular, an attribute can be set to a vector or to a key-value map (usually referred to as an "object") at creation/update time. These values are retrieved at query and notification time
The Problem
I was able to correctly define the value of these attributes through creation/update operations in Orion Context Broker but when these values are stored in my STH-Comet database they are stored as an "escaped" string (see the detailed example below).
{
"_id" : ObjectId("5bdb611d9aa6ab00017e8c82"),
"recvTime" : ISODate("2018-11-01T20:25:01.640Z"),
"entityId" : "foo",
"entityType" : "foo",
"attrName" : "bar",
"attrType" : "T",
"attrValue" : "[{"nested_attr1":"v1"},{"nested_attr2":"v2"}]"
}
Question
So my question is, what did I do wrong? Maybe I missed some detail within my configuration?
Thank you in advance
fiware fiware-orion fiware-cygnus
add a comment |
up vote
2
down vote
favorite
Background
I'm using the following Generic Enablers in a specific application that I am building over FIWARE:
- Orion Context Broker
- CYGNUS NGSI
- STH-Comet
Also, I'm using MongoDB database, in order to persist all raw historical data received by Cygnus. To do so, I've configured a MongoDB Sink in CYGNUS, as indicated here.
Then I have a context entity, for which some attributes has structured values, instead of simple types like string. For example: a collection or a dictionary.
Fortunately this is possible!! Check the Orion's official documentation for details.
Apart from simple values such as 22.5 or "yellow", you can use complex structures as attribute values. In particular, an attribute can be set to a vector or to a key-value map (usually referred to as an "object") at creation/update time. These values are retrieved at query and notification time
The Problem
I was able to correctly define the value of these attributes through creation/update operations in Orion Context Broker but when these values are stored in my STH-Comet database they are stored as an "escaped" string (see the detailed example below).
{
"_id" : ObjectId("5bdb611d9aa6ab00017e8c82"),
"recvTime" : ISODate("2018-11-01T20:25:01.640Z"),
"entityId" : "foo",
"entityType" : "foo",
"attrName" : "bar",
"attrType" : "T",
"attrValue" : "[{"nested_attr1":"v1"},{"nested_attr2":"v2"}]"
}
Question
So my question is, what did I do wrong? Maybe I missed some detail within my configuration?
Thank you in advance
fiware fiware-orion fiware-cygnus
How the information is stored is fine, but it is an internal aspect of STH. It is better to describe the issue in API terms. So, could you edit your question to include an example of GET operation on the STH API with the associated result you get, please? Thanks!
– fgalan
Nov 5 at 19:22
The problem is that I need the document that is stored in MongoDB to be well formed, respecting a JSON structure. This is because I have applications that read directly from this database. How ever, you are right that the title of the question refers to STH-Comet, so I changed it to reflect the question better.
– Emiliano Viotti
Nov 7 at 15:32
You should access to STH information using the STH API, not direct access to DB. Note that database model is an internal aspect of the component that could even change between versions (while the API remains the same) so breaking any integration based on it. Could you elaborate on the reason behind accessing DB directly instead of using the API, pls? Thanks!
– fgalan
Nov 8 at 16:24
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Background
I'm using the following Generic Enablers in a specific application that I am building over FIWARE:
- Orion Context Broker
- CYGNUS NGSI
- STH-Comet
Also, I'm using MongoDB database, in order to persist all raw historical data received by Cygnus. To do so, I've configured a MongoDB Sink in CYGNUS, as indicated here.
Then I have a context entity, for which some attributes has structured values, instead of simple types like string. For example: a collection or a dictionary.
Fortunately this is possible!! Check the Orion's official documentation for details.
Apart from simple values such as 22.5 or "yellow", you can use complex structures as attribute values. In particular, an attribute can be set to a vector or to a key-value map (usually referred to as an "object") at creation/update time. These values are retrieved at query and notification time
The Problem
I was able to correctly define the value of these attributes through creation/update operations in Orion Context Broker but when these values are stored in my STH-Comet database they are stored as an "escaped" string (see the detailed example below).
{
"_id" : ObjectId("5bdb611d9aa6ab00017e8c82"),
"recvTime" : ISODate("2018-11-01T20:25:01.640Z"),
"entityId" : "foo",
"entityType" : "foo",
"attrName" : "bar",
"attrType" : "T",
"attrValue" : "[{"nested_attr1":"v1"},{"nested_attr2":"v2"}]"
}
Question
So my question is, what did I do wrong? Maybe I missed some detail within my configuration?
Thank you in advance
fiware fiware-orion fiware-cygnus
Background
I'm using the following Generic Enablers in a specific application that I am building over FIWARE:
- Orion Context Broker
- CYGNUS NGSI
- STH-Comet
Also, I'm using MongoDB database, in order to persist all raw historical data received by Cygnus. To do so, I've configured a MongoDB Sink in CYGNUS, as indicated here.
Then I have a context entity, for which some attributes has structured values, instead of simple types like string. For example: a collection or a dictionary.
Fortunately this is possible!! Check the Orion's official documentation for details.
Apart from simple values such as 22.5 or "yellow", you can use complex structures as attribute values. In particular, an attribute can be set to a vector or to a key-value map (usually referred to as an "object") at creation/update time. These values are retrieved at query and notification time
The Problem
I was able to correctly define the value of these attributes through creation/update operations in Orion Context Broker but when these values are stored in my STH-Comet database they are stored as an "escaped" string (see the detailed example below).
{
"_id" : ObjectId("5bdb611d9aa6ab00017e8c82"),
"recvTime" : ISODate("2018-11-01T20:25:01.640Z"),
"entityId" : "foo",
"entityType" : "foo",
"attrName" : "bar",
"attrType" : "T",
"attrValue" : "[{"nested_attr1":"v1"},{"nested_attr2":"v2"}]"
}
Question
So my question is, what did I do wrong? Maybe I missed some detail within my configuration?
Thank you in advance
fiware fiware-orion fiware-cygnus
fiware fiware-orion fiware-cygnus
edited Nov 7 at 15:35
asked Nov 2 at 18:37
Emiliano Viotti
469113
469113
How the information is stored is fine, but it is an internal aspect of STH. It is better to describe the issue in API terms. So, could you edit your question to include an example of GET operation on the STH API with the associated result you get, please? Thanks!
– fgalan
Nov 5 at 19:22
The problem is that I need the document that is stored in MongoDB to be well formed, respecting a JSON structure. This is because I have applications that read directly from this database. How ever, you are right that the title of the question refers to STH-Comet, so I changed it to reflect the question better.
– Emiliano Viotti
Nov 7 at 15:32
You should access to STH information using the STH API, not direct access to DB. Note that database model is an internal aspect of the component that could even change between versions (while the API remains the same) so breaking any integration based on it. Could you elaborate on the reason behind accessing DB directly instead of using the API, pls? Thanks!
– fgalan
Nov 8 at 16:24
add a comment |
How the information is stored is fine, but it is an internal aspect of STH. It is better to describe the issue in API terms. So, could you edit your question to include an example of GET operation on the STH API with the associated result you get, please? Thanks!
– fgalan
Nov 5 at 19:22
The problem is that I need the document that is stored in MongoDB to be well formed, respecting a JSON structure. This is because I have applications that read directly from this database. How ever, you are right that the title of the question refers to STH-Comet, so I changed it to reflect the question better.
– Emiliano Viotti
Nov 7 at 15:32
You should access to STH information using the STH API, not direct access to DB. Note that database model is an internal aspect of the component that could even change between versions (while the API remains the same) so breaking any integration based on it. Could you elaborate on the reason behind accessing DB directly instead of using the API, pls? Thanks!
– fgalan
Nov 8 at 16:24
How the information is stored is fine, but it is an internal aspect of STH. It is better to describe the issue in API terms. So, could you edit your question to include an example of GET operation on the STH API with the associated result you get, please? Thanks!
– fgalan
Nov 5 at 19:22
How the information is stored is fine, but it is an internal aspect of STH. It is better to describe the issue in API terms. So, could you edit your question to include an example of GET operation on the STH API with the associated result you get, please? Thanks!
– fgalan
Nov 5 at 19:22
The problem is that I need the document that is stored in MongoDB to be well formed, respecting a JSON structure. This is because I have applications that read directly from this database. How ever, you are right that the title of the question refers to STH-Comet, so I changed it to reflect the question better.
– Emiliano Viotti
Nov 7 at 15:32
The problem is that I need the document that is stored in MongoDB to be well formed, respecting a JSON structure. This is because I have applications that read directly from this database. How ever, you are right that the title of the question refers to STH-Comet, so I changed it to reflect the question better.
– Emiliano Viotti
Nov 7 at 15:32
You should access to STH information using the STH API, not direct access to DB. Note that database model is an internal aspect of the component that could even change between versions (while the API remains the same) so breaking any integration based on it. Could you elaborate on the reason behind accessing DB directly instead of using the API, pls? Thanks!
– fgalan
Nov 8 at 16:24
You should access to STH information using the STH API, not direct access to DB. Note that database model is an internal aspect of the component that could even change between versions (while the API remains the same) so breaking any integration based on it. Could you elaborate on the reason behind accessing DB directly instead of using the API, pls? Thanks!
– fgalan
Nov 8 at 16:24
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53124128%2fstore-structured-context-values-for-attributes-using-fiware-orion-context-broker%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How the information is stored is fine, but it is an internal aspect of STH. It is better to describe the issue in API terms. So, could you edit your question to include an example of GET operation on the STH API with the associated result you get, please? Thanks!
– fgalan
Nov 5 at 19:22
The problem is that I need the document that is stored in MongoDB to be well formed, respecting a JSON structure. This is because I have applications that read directly from this database. How ever, you are right that the title of the question refers to STH-Comet, so I changed it to reflect the question better.
– Emiliano Viotti
Nov 7 at 15:32
You should access to STH information using the STH API, not direct access to DB. Note that database model is an internal aspect of the component that could even change between versions (while the API remains the same) so breaking any integration based on it. Could you elaborate on the reason behind accessing DB directly instead of using the API, pls? Thanks!
– fgalan
Nov 8 at 16:24