Filter by attribute in nosignal rules

[manucarrace]

Current implementation of nosignal rules only allows to filter by Id and type. It would be nice to have an aditional filter by attribute, both at context broker level and mongo level.

More details about this issue to be provided.

[fgalan]

I understand the issue refers to "attribute existance".

NGSIv2 API (case when PERSEO_CHECK_NON_SIGNAL_BY_API is in use):

From: https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#simple-query-language

The unary statements are used to check for the existence of the target property. E.g. temperature matches entities that have an attribute called 'temperature' (no matter its value),

For instance, this is the filter to match entities that have an attribute named temperature:

?q=temperature

MongoDB query (case when PERSEO_CHECK_NON_SIGNAL_BY_API is not in use):

From https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/admin/database_model.md#entities-collection

attrNames: an array of strings. Its elements are the names of the attributes of the entity (without IDs). In this case, the "." to "=" replacement is not done.

So for instance a query like the following one matches entities that have an attribute named temperature

db.entities.find({attrName: "temperature"})

[manucarrace]

Mybe not only existance but attribute value

[fgalan]

Mybe not only existance but attribute value

Which value should be checked? Could you formulate the attribute value condition (in English) so I can "translate" to queries?

[manucarrace]

I would like to check the absence of data only for entities of type Streetlight with temperature > 100 or flag == true

[fgalan]

I think I misunderstood the original description of this issue...

Considering the new statement

I would like to check the absence of data only for entities of type Streetlight with temperature > 100 or flag == true

Let's consider just only one condition:

I would like to check the absence of data only for entities of type Streetlight with temperature > 100

would be

• CB API: ?q=temperature>100
• MongoDB query: db.entities.find({"attrs.temperature.value": {$gt: 100}})

I would like to check the absence of data only for entities of type Streetlight with flag == true

would be

• CB API: ?q=flag:true
• MongoDB query: db.entities.find({"attrs.flag.value": true})

The problem is with the or condition. CB API doesn't support or. But if we change to and, this way:

I would like to check the absence of data only for entities of type Streetlight with temperature > 100 and flag == true

would be

• CB API: ?q=temperature>100;flag:true
• MongoDB query: db.entities.find({"attrs.temperature.value": {$gt: 100}, "attrs.flag.value": true})

[manucarrace]

Possible use case in order to ease the understanding of the issue. In a given subservice I could have some entities cosidered as "static" (they don't receive periodic data). These entities, could be of the same type than others consided as "dinamic" (they receive data on a period basis).

For instance, I may have several streetlights sending data to the platform but some other just for inventary purposes. In this case, I would like to check the absence of data only for those entities considered as dinamic. I can mark these entities with a flag attribute and then state this attribute in the rule in order to filter the entities.

[fgalan]

Possible use case in order to ease the understanding of the issue. In a given subservice I could have some entities cosidered as "static" (they don't receive periodic data). These entities, could be of the same type than others consided as "dinamic" (they receive data on a period basis).

For instance, I may have several streetlights sending data to the platform but some other just for inventary purposes. In this case, I would like to check the absence of data only for those entities considered as dinamic. I can mark these entities with a flag attribute and then state this attribute in the rule in order to filter the entities.

So I understand we don't need combine several filters at the same time (only one, i.e. flag equality for true). Thus, in my opinion this fits perfectly with the above proposal.

[AlvaroVega]

Related PR about nosignal filters: #726