SchemaEvolution

From Mu2eWiki
Revision as of 23:30, 7 March 2018 by Rlc (talk | contribs) (Created page with " ==Introduction== From time to time an Mu2e art product needs to be updated. The members of a class may be deleted, added or transformed. In this case, we could introduce a...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

From time to time an Mu2e art product needs to be updated. The members of a class may be deleted, added or transformed. In this case, we could introduce a new product and keep it separate from the old product. If the redesign is extreme, this might make sense. More often, the change is minimal, with only a member or two affected. In this case we would like to let the old product evolve into the new version.

We will assume the following:

  • old release will keep writing the old version
  • new releases will want to read the old or new version
  • new releases will only have the new version n memory and only write the new version

There are two main cases, which follow

Variable Movement

The simplest case is adding new variables with unique new names or removing variables fro a class. When root writes a dictionary of a class, it examines the code and write a summary of the variable names and types. This list is then stored in the art file with the binary instance of the class. If the change adds, deletes or moves these variables, it can follow the changes through the dictionary. For example if it sees the object on disk was declared as

class : {
  int va;
  int vb;
  int vc;
}

and it sees the same class in memory has structure:
class : {
  int vb;
  int va;
  float vd
  float vc;
}
then it will know to do, after reading the object from disk,swap the memory for va and vb, make the conversion of int(vc) to vc ??, and set vd to zero??.  The trick is that is the following the variable names through the dictionary. 

We do not need to do anything for this schema evolution to work correctly.

Transformation of Variables

Sometimes the variable needs to be transformed on input. For example, supposed in the old class there was a flag containing two bits and in the new class these are stored as two bools. root can't keep track of this by following the variable names, so we have to tell it what to do. The solution is to write a code snippet, in this case, something like bool1 = flag&1 bool2 = flag&2 and inserting it in the classes_def.xml file, in the stanza for the object which requires it. You can put any amount of code here, even include files. You can define the transformation to apply only certain versions of the class (input or output). Here are the specific art instructions for inserting the transformation code.

Versions of classes

It is possible to assign a version number to each class in the classes_def.xml file. If class T changes, you need to increment the version for class T only, not the classes that include this class by template. This only beceom s a convenience We don't expect that