Do named query bindings "batch" for multiple parameter changes

[zacht]

I have a Vision window that contains a table populated this way:

• A named query binding populates the data for the table.
• The named query has 5 parameters.
• Each parameter of the named query binding is bound to a custom property on the Vision window root container.
• Each of these custom properties receives its value via an expression binding to the same dataset (I'll call it the 'parameter dataset' to avoid confusion with the table dataset above).
• The parameter dataset is populated by a binding which polls.
• When the parameter dataset is updated (via its polling behavior), at least three of the custom properties change. This should happen at roughly the same time since they are all bound to the parameter dataset.

Does the named query binding populating the data for the table run as many times as there are custom property changes (since I assume it's subscribed to all the custom properties), or are the changes "batched" somehow since they all happen so closely in time to each other? If the query is run multiple times in this configuration, does anyone have suggestion on a better configuration that avoids this behavior?

[PGriffith]

The query will be "kicked off" multiple times. There's no debouncing or anything because expressions are deliberately event driven and non-stateful.

In Vision, the only method you have to get more control than this is with scripting.

[bmeyers]

I have used this function to call a refresh on my tables when I want.

https://docs.inductiveautomation.com/display/DOC81/system.db.refresh

[pturmel]

@zacht

• Each parameter of the named query binding is bound to a custom property on the Vision window root container.
• Each of these custom properties receives its value via an expression binding to the same dataset (I'll call it the 'parameter dataset' to avoid confusion with the table dataset above).

Eww. Circular reference? Don't do that.

[zacht]

@zacht

Each of these custom properties receives its value via an expression binding to the same dataset (I'll call it the 'parameter dataset' to avoid confusion with the table dataset above).

The same dataset as each other, not the same dataset as is populated by the named query in question. I could have described the setup better, but I don't think it's circular.

There are two datasets the one at the bottom, aggregationInfo, collects the data that needs to be passed into various parameters in the named query. 'aggregationInfo' is a custom property itself and polls every 30 seconds to get it's data. The dataset at the top is populated by a named query which uses the values in aggregationInfo as it's parameters. In vision, you can't (that I'm aware of) drill into a dataset to get an individual value as a parameter for a named query. To get around this limitation, I had a layer of custom properties in the middle, each of which was bound to aggregationInfo to drill down to the specific value. These single-value custom properties were used as the parameter values in the vision table named query.

A {very} rough mock-up. Ignore the crow's foot notation. Data flows from bottom to top:

[pturmel]

Ok, not circular. I would have expected a few milliseconds of debounce on the query binding. Vision does this for other database-related stuff, like EasyChart pen queries.