Possible bug in adding query to sensors

[hfaghihi15]

Following the basics of our framework, we execute models by tracing sensors back based on their input and output production. If we add queries as blind functions or expressions, the problem will be that we can systematically find the tracebacks and call the sensors properly.

e.g: in the query, the result of a sensor producing the property pos is being used but pos is not given as input to the new sensor. Thus, we will never run the pos sensor and this will result in an error when executing the model. While previously, we had to pass pos as input to the model to be able to use its results.

[guoquan]

True. The query might break the chain of calling dependency. Maybe we will need the datanode to have a callback to trigger sensors.

[hfaghihi15]

The problem is that Datanode also doesn't know about the sensor names and their execution.

[hfaghihi15]

Is there any documentation on access functions to the Datanode?! @auszok

[hfaghihi15]

Communication

We need to know how to change the communication to the data node. All sensors have to be changed to use the Datanode instance instead of a context dictionary. I am assuming to receive and send data in this format.

{
1: value 
2: value 
3: value
6: value
8: value
}

This helps to find the appropriate id for updates and get methods.

Selection based on pre variable

Do we assume that the filter query just sends some filtering on the same concept and then the pre class should be used to select a specific column?

Update problem

We will not know about the chain of execution when using queries as input.

Query format

What should be the format? Is it a function passed to the sensor? Is the concept going to be limited to the current concept on the sensor? ( Each sensor is attached to a property and a sensor when instantiated) like:

def query(datanode, concept)
    query = datanode.somequery
    return query # this is a list of datanode objects

A wiki for datanode function

We should have a wiki for data node access to see how to filter columns, iterate and etc. These functions are useful in providing a transparent forward function for the user.

Forward function

Should we make the forward function based on one instance at a time or keep it to be able to loop over the incoming data?!

[guoquan]

As I am implementing the QuerySensor, I am assuming the chain of execution is declared by pres and edges. In the sensor forward(), the datanode(s) are only guaranteed to have attributes that are matching the pres. Should this address the issue?

[hfaghihi15]

As I am implementing the QuerySensor, I am assuming the chain of execution is declared by pres and edges. In the sensor forward(), the datanode(s) are only guaranteed to have attributes that are matching the pres. Should this address the issue?

It solves the problem for the forward call. However, I am not sure where the queries are gonna be. If queries are written and given to the sensors in free style then the problem still exists.