Pasha Murat wrote: > Talking about persistency issues one could distinguish "forward" > and "backward" compatibility of I/O mechanisms. > > "Forward" compatibility means that it is possible to read old data files > with the new (probably modified) code. "Backward" compatibility means that > it is possible to read *new* data files with the old version of code. > > Apparently ROOT support of schema evolution - with Streamer(..) methods > which could be written by a user - provides "forward" compatibility. > I suppose that you have inverted the usual definition of "forward" and "backward"compatibility. > Let's now assume that we adopt the following convention: whenever a class > definition is modified, its Streamer method either is not being changed or is > only allowed to append new words to the saved (persistent) part of the object. > In this case it is logically possible to read the datafile written with the > new version of the code using the old version (in this case one can't > use appended information - but the old version of the code "doesn't know" > about it anyway). > > The only thing needed is to increment byte counter in an I/O buffer in a way > independent on the user, when reading the next object - object in the buffer is > longer than its part read by an "old" Streamer() method. > > Although this possibility is not something one needs urgently, > in a long time scale it might be important to have it implemented. > > You are perfectly right. This will also provide additional robustness in caseof an inconsistency in one (or more) Streamer functions. Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:22 MET