Calib metadata dbs interface enhancements

Calibration metadata database interface enhancements

Use cases

I can think of a couple that rdbGUI in its current incarnation doesn't handle well or at all. Are there others?

Some program or script creates the calibration data. It would be natural for the same program or script to enter the calibration into the database.
Several calibrations are made at approximately the same time, perhaps from the same input. They will share many characteristics, hence column values. It's tedious to use rdbGUI to enter the same set values several times.

If 2. is the problem, it could perhaps be addressed by making some enhancements to rdbGUI so that it would remember values for those columns – most of them – which tend to be the same for a collection of calibrations.

User-supplied columns
Field name	Sticky?	Default/Initial value
instrument	Yes	(none)/"LAT"
flavor	Yes	"vanilla"
calib_type	No	(none)/"TKR_DeadChan"
data_ident	No	(none)
data format	Usually	(none)/"XML"
vstart	Usually	(none)
vend	Usually	"2037-12-31"
input_desc	No	null
notes	No	null
proc_level	Usually	"TEST"
completion	Usually	(none)/"OK"
locale	Yes	"orbit"
fmt_version	Usually; especially now while it's not used in a serious way	null
prod_start	Yes. Normally null upon INSERT	null
prod_end	Yes. Normally null upon INSERT	null
data_size	Wouldn't be if used	null

Maintaining self-consistency

In the production database, there should be no more than one calibration of a particular calib_type of production quality valid for any instant of time. When entering a new calibration, the natural thing to do is to set vend to its default value (Dec. 31, 2037), however the same operation should also set the value of vend for the previous production calibration of that type to the vstart of the new one, so that there is no overlap. Updates as well as inserts can give rise to this situation; that is, can make it necessary to modify some other row or rows in order for the database to continue to satisfy some consistency condition. It would be well to also have a means of checking (triggered on demand rather than by an update or insert) whether the database satisfies some set of conditions.

Last modified: