I have a question about the tagPath return column on the system.tag.queryTagCalculations function.
If you use a tagPath list with back slashes, it will return the entire tagPath with its data result.
However, if you use a tagPath list with forward slashes, it will only return the tag name with its data result.
My questions are as follows:
- Is this by design?
- Will this functionality remain this way to a point where I can depend on my results having a full tagPath in order to sync up with adjacent datasets?
That’s probably a bug. Elements of a tag path are documented to be separated by forward slashes. I wouldn’t rely on it.
As Phil said, I wouldn’t rely on an undocumented/unintended function staying.
If you want to guarantee column names remain consistent across datasets and updates, you should use the aliases parameter in the
system.tag.queryTagCalculations(), that functionality is documented and not likely to change anytime soon.
Great information and feedback, much appreciate.
However, it leads to a few other questions.
- Will this function always return the same number of data points as queried?
- Will this function return the data in the order the path list is constructed in so it can be indexed and joined in with adjacent datasets/lists?
That is my concern.
(1) if i cannot rely on using an undocumented method of getting back a full tag path and (2) if I cannot rely on the original method returning the data back in a specific order… how can I use this function to effectively poll 1000’s of tags on any one request and process them into another dataset/list?
What exactly are you trying to do? I’m not sure what you mean by process them into another dataset/list?
From the manual:
This is useful when you wish to aggregate Tag history collected over a period of time into a single value per aggregate. If you want multiple values aggregated to a single time slice (i.e., hourly aggregates for the same Tag over an 8 hour period) consider using system.tag.queryTagHistory
On top of that, databases do not have a guaranteed order, by design. That is in fact the entire reason of the Order By clause. Instead the data generally has a “key” which allows for identifying the data which is related. In the case of
system.tag.queryTagCalculations this is done by looking at the aggregate. You can then look through the dataset and pull the pertinent information.
The method I am using is as follows:
I have a database table that hold my tag names, configuration, paths, etc., that I am pulling into a list of lists (to include additional process/business data). While looping through this list, I am creating a separate tag list for use with this function. Call the function into a dataset object. Then I am looping through my list of lists and polling the results from this function by index to get its value for processing it further from there.
I need to be able to depend on either its correct indexing location or a full tag path to lookup.