...

Mike Browne writes:  I think Valerio's comments above are pretty spot on.  The integer is essentially a version/commit number.  It uniquely identifies everything at a particular moment in time... you change stuff, you get a new key/number.  We're saving a complete history, with the idea if it gets too much at some point, someone in the future will write a history-pruning tool.

Two Suggested New Tools

Merging Schema Changes

issue: we don't handle merging of schema changes to the config objects

ric's proposal:
- script to read db and write json file
- modify ts_config_store.py to put the new schema in dbase
- third script applies settings from json file to the dbase ignoring the ones
  that are dissimilar
(get_config.py has some of the tools to do this)

cpo proposal:
- one script (configdb_modify.py) that reads the configdb json, modifies it (with python code)
  and writes it back (a plug or a minus: we no longer have a script that knows the official
  state of the schema: the database itself is the source of truth).
  - if we ever lost the database we no longer know the configdb schemas

item 1:

ts_config_V1:
config[group][0][rate]=10Hz
             [1][rate]=100Hz
             [2][rate]=100Hz

need a procedure to produce:

ts_config_V2:
config[group][0][rate]=10Hz
             [2][rate]=100Hz

or

ts_config_V2:
config[group][0][rate]=10Hz
             [1][rate]=100Hz
             [2][rate]=100Hz
             [4][rate]=100Hz

Hiding/Removing Old Configdb Objects

ability remove and hide (in the control gui) detector configurations that aren't needed anymore
(hide: prepend an "_"?, rename timing_1 to _timing_1?)
rename = delete+create