Skip to content

Conversation

@abigailalexander
Copy link
Collaborator

This PR adds a Databrowser widget, which builds on top of the existing StripChart widget and adds archived data.
Other changes made:

  • Added .plt file parser. Many of the properties are different to .bob and .opi and required their own parser
  • In order to load the .plt file, many of the parsing functions have been made async to account for the file fetch. The Device and TabContainer components were also impacted by this and have been updated
  • Modified some Striptool functionality - data is now stored in a useRef to prevent archived data being overwritten, also implemented bufferSize and updatePeriod properties to limit size of datasets and how often data updates.

};
});
});
fetchedData = tmpData;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think fetchedData is overwritten on every iteration of the outer for loop. That does not matter if there is only one archiver, but for multiple archivers it's a bug.
I'm guessing that it should be: fetchedData = [...fetchedData, ...tmpData]

Can we guarantee the order of the data returned by the archivers? ie would the concatenated data from multiple data archives be in increasing date/time order or would we need to merge sort it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot, thanks for that. My test files only had one archiver, so I missed this. The requests per archiver should all be for the same period of time, so it would be need to be merge sorted to combine with data from the other archivers. I'm not sure how often someone wants to plot data from different archivers on the same plot, but added this functionality just in case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the interest of avoiding some scope creep, I think I would explicitly support one archiver, log a warning if there are more than one and add a ticket on the backlog to track a feature to support multiple archivers. If it turns out we need to support more than one archiver we can prioritise the ticket.

Copy link
Collaborator

@GregJHarris GregJHarris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved Thank you

};
});
});
fetchedData = tmpData;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the interest of avoiding some scope creep, I think I would explicitly support one archiver, log a warning if there are more than one and add a ticket on the backlog to track a feature to support multiple archivers. If it turns out we need to support more than one archiver we can prioritise the ticket.

@abigailalexander abigailalexander merged commit 41109e3 into master Oct 31, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants