Many of the functions described below should be available from a gui. In what follows, requirements or recommendations specific to such a gui are indicated with this background color.
As of each metadata entry has the following fields:
| Field | Type | Default | Extra |
|---|---|---|---|
| ser_no | mediumint(9) | NULL | auto_increment |
| instrument | varchar(16) | ||
| calib_type | varchar(20) | ||
| flavor | varchar(30) | vanilla | |
| data_fmt | varchar(10) | ||
| data_size | int(11) | NULL | |
| vstart | datetime | NULL | |
| vend | datetime | NULL | |
| enter_time | timestamp(14) | NULL | |
| locale | varchar(30) | orbit | |
| fmt_version | varchar(12) | NULL | |
| completion | enum('OK','INC','ABORT') | NULL | |
| proc_level | enum('PROD','TEST','DEV','SUPSED') | TEST | |
| prod_start | datetime | NULL | |
| prod_end | datetime | NULL | |
| creator | varchar(255) | NULL | |
| uid | varchar(12) | ||
| data_ident | varchar(255) | ||
| input_desc | varchar(255) | NULL | |
| notes | varchar(255) | NULL |
Back to
The typical client wishing to add a row to the table, particularly from a gui, will not want or need to specify values for all columns. The table below reflects the point of view of the interactive user. We're only interested in those fields which cannot be sensibly set without human intervention. Some, like ser_no, can or must be set automatically to their proper values. Rows for these items are grey. They will not appear at all in the gui. Some others are only informational or unused. Users may set them, but they don't have much effect. These rows are yellow. If not set, they will get the default values appearing in the table. Of the remainder, some, like calib_type, although not enum as far as sql definition is concerned, are typically used as enum, with an option to supply something not in the standard list. This is denoted in the Type column of the table below by specifying enum and putting an ellipsis at the end of a list of specific values. Note Default here means something different than it did in the first table. Default of "none" means the user must supply something or the row will not be added.
| Field | Type | Default | Comments |
|---|---|---|---|
| ser_no | mediumint(9) | N/A | auto_increment |
| instrument | enum('LAT','EM','CU', ...) | (none) | |
| calib_type | enum('TKR_DeadChan', 'TKR_HotChan', 'CAL_Ped', 'CAL_ElecGain', 'CAL_MuSlope',...) | (none) | |
| flavor | enum ('vanilla', 'ideal', ...) | (none) | |
| data_fmt | enum('XML', 'ROOT',...) | (none) | Could temporarily default to XML, but once more than one format is supported,there will be no sensible default. |
| data_size | int(11) | "unknown" | This field is at most informational, currently entirely unused |
| vstart | datetime | (none) | Must be <= vend |
| vend | datetime | (none) | Must be >= vstart |
| enter_time | timestamp(14) | N/A | |
| locale | enum('orbit', 'NRL', 'SLAC', ...) | (none) | |
| fmt_version | varchar(12) | "unknown" | Currently this information isn't used, but someday it will be. No ideas so far on how to help user with this one. |
| completion | enum('OK','INC','ABORT') | (none) | |
| proc_level | enum('PROD','TEST','DEV','SUPSED') | (none) | |
| prod_start | datetime | NULL | Set automatically to value of enter_time if dataset proc_level = 'PROD' |
| prod_end | datetime | NULL | Always initially NULL |
| creator | varchar(255) | N/A | |
| uid | varchar(12) | N/A | |
| data_ident | varchar(255) | (none) | |
| input_desc | varchar(255) | "No input desription submitted" | |
| notes | varchar(255) | "No notes submitted" |
Since the display of existing data in the table may affect content of a row to be added, it should be possible to keep the display of existing data visible while parameters for a new row are being input. Perhaps have a separate window to input selection criteria for display and to contain the display. In fact, might be nice to have more than one display window. Each should have a refresh or go button, causing the query which generated the display to be reissued.
From the second table we see, there are a minimum of 10 values to be supplied by the user. Since there is no easy or natural way to enforce an input ordering on the fields, probably should have separate controls for each field and also a go button. At the time go is pushed the input can be checked for completeness and consistency.
Many of the fields typically have values from a known set. For such fields one could use a menu, containing the known possibilities in the order most likely to be convenient for the user, with one additional item for arbitrary typed input. For vstart and vend provide separate controls for year, month, date and time. The first three at least should allow or perhaps require selection rather than typing.
It will be difficult to provide much help for data_ident, typically used to contain the complete file path for the calibration's bulk data. Perhaps when a strategy for storing production files has been implemented some part of the file path will be deducible from some of the other fields, such as calib_type. If so, will need a mechanism to insure the data_ident is filled last, or at least after the fields on which is it likely to depend.
Back to
Certain requirements are placed on the set of calibrations with proc_level = 'PROD'. Ideally, for any instant of time there should be at most one calibration of a particular type, flavor and instrument whose validity interval includes that instant. For the LAT itself, for the duration of the flight, we also insist there be at least one production-level calibration of flavor "vanilla" of each of essential (how defined?) calibration type.
It is tempting to say the metadata description is implicit in the SQL table structure. In this case an SQL script creating the table is a complete concrete representation of the metadata structure. However as described above there are additional constraints on entries which are not representable in an SQL table definition. They need to be handled somehow by the code. We could consider coming up with yet another mode of description which would be sufficient to define the SQL tables but also could describe the additional constraints. It would then be possible to write utilities to create the table and do all the other desired operations in a generic way, entirely data-driven by this underlying description. XML is a reasonable candidate format for this description.