What should an interactive interface to the metadata table do?

1. Make it relatively easy to add new correct (syntactically correct and semantically sensible) rows.
2. Allow modification of certain fields of existing entries, including at least vend and proc_level.
3. Maybe automatically update vend of an existing calibration when a new production calibration of the same calib_type, flavor, instrument is added, or at least ask user whether the change should be made.
4. (lower priority) Display of (subset of?) columns for rows satisfying certain kinds of conditions.

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.

Adding a metadata row

From the second table below, 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.

Columns of metadata table

Table columns, as defined for MySQL, look like this:

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.