RE: [ROOT] Changing class definition in split level=2

From: Magestro Daniel (D.Magestro@gsi.de)
Date: Fri Aug 10 2001 - 10:59:14 MEST


Rene,

Hi - thanks for your response... unfortunately, the page reference you sent
me (migrating to Root 3) does not relate to the problem I have.  The problem
is that, in our split level = 2 scheme, the data i/o is not handled by the
individual class streamers but by the TClonesArray streamer. Therefore, we
cannot simply increment the class version and write a custom streamer to
read old files because the class's streamer is NOT touched.  

My fear is that we lose backward compatibility due to our dependence on the
TClonesArray streamer.  Is there a solution for this?  As I wrote before,
migrating to Root 3 doesn't solve the problem for .root files which were
created for v2.25 with a different class definition because the files were
created with the TClonesArray streamer...

Thanks again,
Dan

| From: Rene Brun [mailto:Rene.Brun@cern.ch]
| Sent: Friday, August 10, 2001 9:23 AM
| Subject: Re: [ROOT] Changing class definition in split level=2
| 
| Hi Daniel,
| 
| Please read the discussion on the migration to the new scheme at page 204 
| of the Users Guide.
| 
| Rene Brun
| 
| Magestro Daniel wrote:
| > 
| > Hi all,
| > 
| > I have read old roottalk posts as well as the latest Root manuals, but I
| > cannot find the solution to a basic problem.  (We are currently using
| > v2.25/03.)
| > 
| > In our analysis, all of our data classes use split level = 2.  The 
| > problem is that, if we change a class definition (for example, 
| > changing the name of a data member), adding a custom streamer to 
| > that class does not work because the streaming for the class is done by 
| > TClonesArray/TBranchClones.  The class streamer is not called at all.
| > 
| > ... Is there a way to read our old files created with v2.25/03 if we
| > now change the class def?  We have a large volume of files which fit 
| > this description, and of course we would like to avoid having to 
| > maintain two versions of our code.
| > 
| > Any ideas would be greatly appreciated... thanks,
| > 
| > Dan



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:56 MET