EventStore Table Definitions
EventStore indexes events by syncValues (SV's), where SV = (run #, event #, uid). The uid in this case is a unique ID that is used to disambiguate events in the case where multiple events have the same run and event number. Data will always have uid=1, MC events will be assigned uid's in some scheme to be determined.
EventStore can manage multiple streams of data as well. This feature is not currently used in GlueX.
Here we describe the tables defined by EventStore. Note that the bold names are primary keys in those tables and italic names represents the group index (for faster lookup).
- FileID gives the list of files
- Version gives the list of data versions
- GraphPath gives the dependencies between different data versions
One entry per data and key file.
- fileId is a unique identifier associated with every stored file
- typeID is an index into the FileType table
One entry per key file. Associates key files with particular skims.
- graphId is an index into the GraphPath table (which defines the graphs)
- view is a the name of a skim (e.g. "2track")
- keyFileId is an index into the FileID table
A list of the run/uid pairs stored in the DB.
- type is the internal description of the type of data (e.g. "evio", "rest", "mc", etc.)
- description is a long description of the data type
When files are deleted dateTime and user register who deleted the files and when.
Information about different data versions
- grade is the name of the skim, as in KeyFile table
- timeStamp is the date associated with this version, i.e. the first time this data is considered available. This is conventionally when the data was generated or submitted.
- graphId is an index into the GraphPath
- state is "active" or "disabled"
- svName is the string that describes this data version
- svid is the id associated with this specific version
Can save a long text comment associated with a particular specific version. [NOTE: need to decide what the use case is for this in GlueX.]
Classify SV's into paths
Describe dependencies between graph nodes.
[NOTE: need to clarify how the prev. two tables interact.]
MySQL only. Used for merging? Still investigating...
A visual description of the tables in ESDB is:
There are two different types of grades used by EventStore:
- write grades specify data versions that have been added to the database and can be managed but are not yet ready for general use.
- read grades specify data versions approved to be accessed by end users.
Data versions can be moved from one grade to another
The current list of grades used are:
A more detailed discussion of what happens during injection can be found here