I just experienced a problem with QueryPropertyHistory when querying data from a thing (logged with a Value Stream). When I select a time interval I'm interested in the result might have rows where some values are empty (undefined). However, if I expand the time frame (set an earlier startTime) the rows that were partially empty are usually filled in and there are new rows with some empty values.
I have understood that writing data to streams is asynchronous but I'd expect that the writing should be done one event (row) at a time. This can happen even if there are minutes between the query start time and the actual first "row" time.
Example (start date X, end date Y):
Example (start date X - Z, end date Y):
Any ideas? This really messes up my system.
The same happens if I call the QueryPropertyHistory from a service I created or "manually" from the Thing -> Services -> Generic Services -> QueryPropertyHistory. I've changed only the endDate & startDate (query is empty and maxItems is 500).
Could this be related?
I'm using PostgreSQL through "ThingworxPersistenceProvider".
I've called QueryPropertyHistory in my own service and also through the thing -> Services -> Generic Services -> QueryPropertyHistory (not on any Mashups) with same results. I've changed only the endDate & startDate parameters (query is empty and maxItems is 500). Usually I get about 10 to 20 rows of data.
Has anyone been able to reproduce this behaviour and confirm if it is a bug or an intended feature? Is there some information I could provide that would help pinpointing the problem?
Risto Vaaraniemi If 2 logs/rows are queried in the same timestamp, in a stream or value stream, only the last one is saved. So one log/row per timestamp; if there are more, they are lost and overwritten by the last one. Is this also your case?
Do you mean writing or reading with the same time stamp? I noticed that whole rows are missing if I tried to write multiple rows with the same timestamp
In this case the values do exist in the database but depending on the QueryPropertyHistory start date some values are missing from the first few rows (oldest rows). If I extend the date range (with the start date) the missing values appear but the additional rows may be missing some values. The same goes the other way round: if I narrow down the date range the rows that had all their values may now be missing some values.
I am storing the data using my thing's service, which receives all the data at the same time and and inside the service the values are stored in the thing properties. I'd assume that this would be the preferred way.
One thing occurred to me but I haven't tested it yet...
What would happen if I received and stored a set of values where only some of them would have changed from the last set of values (current value set)? Even if I wrote them all in the thing properties would the non-changed property values recorded with the same time stamp as the changed ones?