ROOT Version: 6.34.04
Platform: linuxx8664gcc
Compiler: GCC 13.3.0
Specifically, I am using the container image ldmx/pro:v4.4.0 on DockerHub. Look there for all the messy details.
I am working in a project where we recently adopted some naming guidelines for our member variables and have now applied them to classes that are serialized by ROOT into output TTrees. However, unsurprisingly, we still have data files with the old schema (old names for member variables) floating around and so I am interested in having some schema rules that rename the member variables when reading the old format.
The full project ldmx-sw is large and takes quite some time to compile, but I’ve been able to partially replicate the issue with a smaller example.
The source code for this example is:
rename-std-map-member-variable.tar.gz (2.3 KB)
The script show in this example, configures and builds the example and then runs the different reading programs to display the issue. Ignoring the configuration and compiling output, we can see that the naive schema rule does not read in the data from the old schema for the std::map member (my_parameter) but does appropriately get the re-named int member (run). I can get the reading to work, but it requires carrying around an extra copy of the std::map member using the old name which I don’t want to do.
Writing Header V1 to file...
Reading file with Header V1:
run: 2
myParameter[example]: 42
Reading file with Header V2:
manual schema evolution rule being applied
run: 2
my_parameter[example]: does not exist
Reading file with Header Both:
manual schema evolution rule being applied
run: 2
my_parameter[example]: 42
- “V1” is the “old schema” with members
int runNumber_andstd::map<std::string, int> myParameters_ - “V2” is the “new schema” with members
int run_number_andstd::map<std::string, int> my_parameters_along with the schema rule that does{ run_number_ = onfile.runNumber_; my_parameters_ = onfile.myParameters_; }. In this simplified case, thestd::mapjust does not read the on-file data, but in a more complex case (see LDMX-Software/ldmx-sw Issue 1815 on GitHub) it seg faults. - “Both” is a “intermediate” schema with members
int run_number_,std::map<std::string, int> myParameters_, andstd::map<std::string, int> my_parameters_along with the schema rule{run_number_ = onfile.runNumber_; my_parameters_ = myParameters_}
This is my first attempt writing schema evolution rules within ROOT. Am I missing something obvious or is this a corner case where I need to do something more than the naive approach?