ISISComputingGroup / ISISComputingGroup/IBEX

Archive: Extract PV History

Open
#2,438 8 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
6
Forks
2
Avg merge
16h 40m
Merged PRs (30d)
2

Description

As a developer, I want to extract the history of one or more PVs from the archive, so that I can display the history to the user. These should be extracted as either log files or events.

#### Acceptance Criteria
1. I can specify one or more PVs to extract from the archive
1. The system returns the history of the specified PVs
1. I can specify start and finish times for the history
1. The system returns the history of the specified PVs only between the specified times
1. I can specify events or time series this will reply with either a list of events or a list of times. These are probably separate functions.
- Time series returns entries [time, value of pv1, value of pv2, ...]
- events log returns [time of change, pv name, value] with the first value being the value at the initial request time (a flag can include/exclude this initial row).
1. The API is restricted, by default, in the number of queried rows so that the database is not overwhelmed.
1. The database is accessed by a specific genie_python user who has resource limits if available in mysql, so that multiple requests can not overwhelm the database. If this can not be done at the database level then it should be done in the genie_python layer.

#### Notes
1. This feature is intended to support the display of graphs (e.g. in ENGIN-X Stress Rig) which might span more than one run. However, it clearly has wider applicability. The extracted PV history could be used to create specialised log files (e.g. dump a limited number of variables to a CSV file)
1. The PVs should be extracted from the archive in a convenient form (i.e. as an array, not as a waveform).
1. PVs are not all logged at the same time (or only logged on change). This is not necessarily what is needed to generate a CSV file (the user would probably expect a list of unchanging values as a function of time). So some thought is required here.
1. Defaults for start & finish times (I would suggest that the user must always specify a start time):
1. If no start time is specified, the feature could return the entire archived history up to the finish time.
1. If no finish time is specified, the feature could return the archived history from the start time up to the present time.
1. If no start and no finish time are specified, the feature could return the entire archived history.
1. **Note:** it might not be desirable to allow start and finish times to default; otherwise, the feature could return a lot of data
1. We should pay attention to the performance of this feature. Repeatedly calling this feature could adversely affect performance,

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.