[STH] Is "neccesary/useful" the return the attribute type in the raw request?

iariasleon commented 9 years ago

example of raw response:

{"contextResponses":[
             {"contextElement":
                          {"attributes":[
                                      {"name":"tempe_0",
                                       "values":[
                                                 {"recvTime":"2015-05-06T08:23:00.673Z",
                                                  "attrValue":"28.1"},                     
                                                 {"recvTime":"2015-05-06T08:23:44.386Z",
                                                  "attrValue":"28.2"},  
                                                 {"recvTime":"2015-05-06T08:25:45.924Z",
                                                  "attrValue":"83.3"}
                                         ]
                                     }
                               ],
                           "id":"room2",
                           "isPattern":false,
                           "type":"room"},
              "statusCode":{
                      "code":"200",
                      "reasonPhrase":"OK"}
            }
  ]
}

The attribute type could change.

gtorodelvalle commented 9 years ago

What do you think, @frbattid ? :)

frbattid commented 9 years ago

If I remember well, Orion behaves as this: if an update context changes the type of an attribute, then it is changed in MongoDB. Thus... should we mimic this behaviour? As you can see, I'm not only talking about maintaining the field, but improving the functionality... and raising new questions xD

Possible scenarios:

The attribute type changes from integer to float. In this case, the change is easy since we are moving to a less restrictive type.
The attribute type changes from float to integer. In this case, should we perform a casting on the already stored values? Or do we cast only when querying for the data (maintaining the old values as float, and coexisting with the new integer values)?
The attribute type changes from integer or float to string. In this case, nothing is stored from the moment the attribute changed.
The attribute type changes from string to integer or float. In this case, we start storing data from the moment the attribute changed.

So, it seems the only problematic scenario is when moving from float to integer. What do you think, floks?

gtorodelvalle commented 9 years ago

In my opinion, in case of moving from floatto integer we should do nothing really... I mean, the new raw data would be stored with the new attributeType and the aggregates would still be float:) The point is if in case of retrieving the raw data we should include the attributeTypeor not in the results :)

My vote would be for YES to align it with the responses provided by the Context Broker when querying for context (/queryContext)... Currently:

{
    "contextResponses": [
        {
            "contextElement": {
                "attributes": [
                    {
                        "name": "temperature",
                        "type": "float",
                        "value": "23"
                    },
                    {
                        "name": "pressure",
                        "type": "integer",
                        "value": "720"
                    }
                ],
                "id": "Room1",
                "isPattern": "false",
                "type": "Room"
            },
            "statusCode": {
                "code": "200",
                "reasonPhrase": "OK"
            }
        }
    ]
}

Although in most cases that information would be redundant... For most cases it would end up being:

"values": [
  {
    "recvTime":"2015-05-06T08:23:00.673Z",
    "attributeType": "float",
    "attrValue":"28.1"
  },                     
  {
    "recvTime":"2015-05-06T08:23:44.386Z",
    "attributeType": "float",
    "attrValue":"28.2"
  },  
  {
    "recvTime":"2015-05-06T08:25:45.924Z",
    "attributeType": "float",
    "attrValue":"83.3"
  }
]

As a developer, when retrieving raw data from the STH, I would always expect the values of the attributes to be a "Number", and probably I would go the for the broader case, this is float. But it is true that since we are retrieving the raw data and the type may change, the developer may be interested on it :)

So, what do you think, should be add the `attributeType' to the data retrieved when asking for raw data?

gtorodelvalle commented 9 years ago

Any thoughts @frbattid ? :)

frbattid commented 9 years ago

+1, I already said that I'm not only talking about maintaining the field, but improving the functionality ;)

Neverthelees, related to what to have said: in case of moving from floatto integer we should do nothing really... I mean, the new raw data would be stored with the new attributeType and the aggregates would still be float. So, are we going to return an interger type but a float value?

gtorodelvalle commented 9 years ago

Including the attributeType in the results provided when the raw data is requested... ;)

No, no, I mean... Let's see it with an example. Let's imagine data about 2 temperature values reaches the STH component with the following shape:

{
  "name" : "temperature",
  "type" : "float",
  "value" : "20.5"
}

and

{
  "name" : "temperature",
  "type" : "integer",
  "value" : "20"
}

From what we just discussed, if the STH is asked for raw data, it would return something such as:

"values": [
  {
    "recvTime":"2015-05-06T08:23:00.673Z",
    "attributeType": "float",
    "attrValue":"20.5"
  },                     
  {
    "recvTime":"2015-05-06T08:23:44.386Z",
    "attributeType": "integer",
    "attrValue":"20"
  }
]

once the PR I am about to send lands :)

On the other hand and regarding aggregates, we are not currently returning any type information, anyhow developers should expect the information provided are normally floats... For example, the "sum" for the previous case would be "40.5" with "samples" equal to "2"... :)

I hope I made myself clear ;)

iariasleon commented 9 years ago

Only to remember, in previous discussions we agreed that in the raw would be stored all notifications received (numeric or not ) and the filter would be before aggregated operations, therefore the attribute type can be anything.

gtorodelvalle commented 9 years ago

Hi @iariasleon , according to https://github.com/telefonicaid/IoT-STH/issues/54#issuecomment-99890934 : "The attribute type changes from integer or float to string. In this case, nothing is stored from the moment the attribute changed." I understood nothing would be store, no raw or aggregated data... :) What do you think @frbattid ? The point is It could make sense to store the raw data no matter if the values of the attributes are aggregatable or not... On the other hand, it seems reasonable to have the raw and the aggregatable data properly synchronized... :) I mean, not having raw data for which no aggregated data is available... :O Uhm, don't really know... :)

gtorodelvalle commented 9 years ago

Ups, the PR (https://github.com/telefonicaid/IoT-STH/pull/81) already landed but we can create a new one in case we decide to store the raw data no matter the attribute type... ;)

telefonicaid / fiware-sth-comet

[STH] Is "neccesary/useful" the return the attribute type in the raw request? #54