Splitability of Classes with Custom Streamer


in Root 5 classes could be split per default even if they had a custom Streamer. Now in Root 6 classes with custom Streamer are not splitable per default for safety reasons.

This can be bypassed using


But this means that we need roughly 70 lines of code at the beginning of every macro which is really ugly because this flag has to be set for each class individually.

Therefore we thought there has to be an easier way to allow the splitting of classes with custom streamers, but since there is almost no documentation for this we could not find any way.

First of all: Is there a way to set this flag already when the custom class is being compiled?

We thought it would be logical to have a flag in the LinkDef which tells Root to make the class splitable even though it has a custom Streamer. It would also be OK if there was a way to bring back the behaviour of Root 5 where the classes with custom Streamers were splitable per default.

I would be very glad if you know a way to achieve this without having 70 lines of code at the beginning of every macro.

Thanks in advance,

ROOT Version: 6.12.06
Platform: Debian 8.11
Compiler: g++ 4.9.2

If a class has a custom Streamer we have to assume that it is for a good reason :). When splitting is used, the custom Streamer is not used at all and thus we are (silently) not doing what the user (likely) intended often leading to corrupted results.

For example some custom streamers are resetting some transient member (for example a cache for a value that is expansive to calculate), without running the Streamer then the member is not reset and the ‘cached’ value is re-used (with the wrong value) for new objects.

So the best way to remove the 70 lines of codes is to remove the custom Streamer. One way to achieve customization of the I/O while preserving splittability is to use I/O customization rules. For example

#pragma read sourceClass="TVertex" targetClass="TVertex" version="[1-]" target="fCache" code={ fCache.Reset(); }"


1 Like

Actually this is quite close to what I told our software coordinator.
These I/O customization rules look quite interesting, I have never seen them before.
Is there somewhere a documentation where their functionality is explained in detail?


There is one more thing that surprised me:
Why are for example the classes TLorentzVector or TVector3 not splitable?
They have no custom streamer and I see no reason why they should not be splitted.

they do have a custom streamer (for historical reasons; they are there to be able to read ancient files that were not self describing, i.e. did not support not using a streamer and technically they could/should be ignored when creating new files).

Unfortunatly I am still not able to find a detailed documentation about how these I/O customization rules work.
I just found a few presentations from you which show a few examples. These are quite helpful to get a feeling about what is possible, but isn’t there any summary of all possible settings and an explanation of them?

see https://root.cern.ch/root/html/io/DataModelEvolution.html and https://root.cern.ch/root/SchemaEvolution.pdf


Thank you, this helps a lot!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.