Mood Thoughts

What follows is a reaction to the discussion Ric and I had with FSW folk on Monday. Haven't yet attempted to merge these ideas with those in the previous MOOD design attempt.

First some definitions:

parameter class

Could also be called a parameter type or kind of parameter. I use the word class because the idea is somewhat analogous to a class in an object-oriented language. It's a description which applies to all instances.

parameter instance

Sometimes also called a parameter value though a parameter instance may consist of many values (e.g., collection of pedestal values) in the usual atomic sense.

FSW file class

Similar to above, could also be called kind of FSW file. Examples would be the AEM part of LATC output, or the kind of file needed by the Event Filter to describe CAL pedestals.

FSW file instance

An individual file belonging to one of the FSW file classes.

So far I can't see any way for MOOT to keep track of configurations in terms of the parameter classes we discussed except to partition them according to what FSW binary file they end up in. To simplify, let's assume that there is a one-to-one correspondence between uploadable binary output and input source. This should be possible according to James, though it isn't required. Then MOOD has to have some tables to keep track of what a particular output binary "means":

• One to describe each of the output file – or corresponding input source file – classes. This one may belong in FMX rather than MOOD, however FSW might not want to get into the business of associating semantics with these file classes (but I don't see how to avoid it, at least implicitly).
• One to describe each of the parameter classes
• One to describe the relation between parameter classes and output file classes

Hope is that these three will settle down at some point and become static.

Then we need to keep track of instances of these things. FMX already handles instances of FSW files, but MOOD has to do the rest: have a table or tables for a parameter value and a way to associate a set of parameter values with a particular FSW file. [Could be that MOOD will also need a table for proposed FSW files. MOOD could assign its own primary key to a file before it's created for use in other MOOD tables. Once the file does exist, the FSW key would be stored in a separate field.] Inbetween there has to be something or someone which can create the FSW source file defined by the set of parameter values. Assume for now this is done offline with no help from MOOT.

Before making an entry in the parameter value table it has to be possible to determine if it already exists; that is, if there is already a row in the table for which some critical subset of fields match those of the proposed new row. The critical subset might vary, depending on the class of the parameter. For example, for some parameter classes the value in a timestamp field might be significant; for others, not.

Similarly, if all the parameter values for a given desired FSW output already exist, one has to be able to determine if the output file already exists (not a foregone conclusion since the parameter values may have been created for some other intended output, or maybe never were used at all).

Given that all these things are going to have to refer to each other, is it practical to separate into two databases? Or can we live without the formality of foreign key constraints?