Hello Richard Wiseman,
I tried to reproduce your issue on Thingworx 7.2.3 with PostgreSQL and couldn't.
I have a Template-set ValueStream and 3 Things that pushed data to this VS.
Have you checked if there is anything related in Thingworx logs?
Thanks Jakub (sorry, typo before!). I think the difference could be something I mentioned in a previous post: "It's a Value Stream attached to a Thing that has a number of logged properties (the one I just checked has 28)." You've only got one logged property; I've got multiple. I think it could be the combination of multiple logged properties changing at different times that's causing the problems.
I don't recall whether I checked the logs for this issue, but I will do so next time I'm logged on.
Sorry, I didn't notice that post of you before - and yes, that could cause this behavior. But not consistently. This behavior happens only, when in the requested number of items there are not all properties. Notice this:
In comparison with:
In the second, it returned maxItems and - because property b and c was missing - a missing row for b and missing property for c.
If I change maxItems to 2, then it would return 4 rows. That's normal behavior of VS (don't know if intended).
In this case, if you'd like to make it more stable and certain, I recommend using Query<Type>PropertyHistory, e.g. QueryNumberPropertyHistory for each property separately. Then it would return only maxItems, without unexpected results.
I've just tried it and yes, if I tick "oldestFirst" the number of rows with all properties populated does indeed correspond to the value of "maxItems" that I specified -- but I still get a whole load of other rows first. Clearly there's a bug in that service!
Also, perhaps I don't understand what "oldestFirst" means: I would expect that to affect the order in which the rows are returned, but the actual data would be the same (i.e. if you don't tick "oldestFirst", you get the same data back but with the rows in the opposite order). I get completely different data, however.
And something else I've just noticed (now that I see there's a pattern) is that if I don't tick "oldestFirst" I get lots of extra data back and then the last exactly N rows (where N is the value of "maxItems") have only one property populated. (So this is the opposite of where I have "oldestFirst" ticked: in that case, it's exactly N rows of all properties having data; whereas in this case it's exactly N rows of only one property having data.) So also a bug, presumably!
I guess I should report it as a bug now that we've confirmed it doesn't do what it should!
Thanks for the suggestion about using alternative services. It's a useful workaround although my reason for using QueryPropertyHistory was that I wanted to display multiple values on a line chart, so I would then have to generate the Infotable for that chart manually is I used the alternative services.
Notice, that Streams are not table-based data storage options, so it's hard to define "n rows". If you request for n items and there is no value for specific property, query returns more rows to assure that result has at least n items for each property. That's my understanding.
And - 'oldestFirst' concerns the query, not result sorting. If you set it to true, the query would return n oldest values that are persisted in this Value Stream and matches other criterias (start date, end date, query).
If you report it as a bug, it would be great if you can share the response - it's kinda interesting.