Rene,
Hi - as a test regarding the use of split level=2 and class def changes, I
have compiled our code with ROOT v3.01 including a simple change of one
datamember name (OLD=sector, NEW=sect). When I read in an old DST file that
was created with the original class def (we used ROOT v2.25), I see the
original datamember name 'sector' in the TBrowser. However, when I do a
TTree->Draw(), I get the following error message:
root [2] T->Draw("HMdcCal1.fData.sector")
Error in <TTreeFormula::DefinedVariable>: sector is not a datamember of
HMdcCal1
In other words, the old datamember name is not known any longer. Also,
although the new datamember name doesn't show up in the TBrowser, I *can* do
a TTree->Draw(), which returns only -1's (sect's initialized value):
root [3] T->Draw("HMdcCal1.fData.sect")
<TCanvas::MakeDefCanvas>: created default TCanvas with name c1
This seems quite strange to me. The TBrowser shows the old name which cannot
be drawn, but the new name is not shown but CAN be drawn.
If I do a T->MakeCode() and look at the generated macro, the original
datamember name is listed as a leaf:
....
T->SetBranchAddress("HMdcCal1.fData.sector",HMdcCal1_fData_sector);
....
Clearly there is some difficulty in reading old files if the class def has
changed, even for tree drawing. Do you have any suggestions? Is this due
to the change in the schema for TBranchClones?
Thanks again for your support, you've been really helpful...
Dan
| -----Original Message-----
| From: Rene Brun [mailto:Rene.Brun@cern.ch]
| Sent: Friday, August 10, 2001 3:12 PM
| To: Magestro Daniel
| Cc: 'roottalk@root.cern.ch'
| Subject: Re: [ROOT] Changing class definition in split level=2
|
|
| Hi Daniel,
|
| Trees with TClonesArray in TBranchClones can be read without problem with
| ROOT version 3, even if the class has evolved. This was one of the
| advantages of the split mode before we introduced the automatic schema
| evolution system.
|
| I can only suggest that you try to read your files with the version 3.
|
| Rene Brun
|
|
| Magestro Daniel wrote:
| >
| > Rene,
| >
| > Hi - maybe I'm missing the point myself. If a TBranchClones from a
| > file is read, then don't the individual class definitions in the
| > loaded libraries have to be the same as in the file? If I change the
| > name of a data member in a class, and then I use this new class with
| > the old file, how does the TBranchClones streamer know about this data
| > member if it's not in the current (loaded) class definition? I don't
| > see how you can read pre-Root3 files with a different class version
| > without using a custom streamer for the class (not supported by
| > pre-Root3 TBranchClones/TClonesArray).
| >
| > Also, the old files (files with v2.25/03) were of course created using
| > the old TBranchClones streamer, not the new one. Maybe this is the
| > source of our problem?
| >
| > I understand that, in the new scheme, the new BypassStreamer()
| > function of TClonesArray, together with TStreamerInfo, takes care of
| > class def changes. But this does not explain how old files, with
| > DIFFERENT class defs from the current ones, can be read properly.
| > Either (a) they can't be read and we lose some backward compatibility,
| > (b) they CAN be read but there is another step which is needed that I
| > don't know, or (c) I'm still missing the point. But if you feel that
| > there's nothing straightforward that we can do to solve this problem,
| > then let me know and we'll deal with the consequences.
| >
| > Thanks again for taking the time... Dan
| >
| > | Hi Daniel,
| > |
| > | I do not understand your point. With the old schem, using
| > | splitlevel=2, TClonesArray Streamer was not used. The TBranchClones
| > | class split each member of the class into a separate branch.
| > | TBranchClones can be read without problems with the new scheme.
| > |
| > | Rene Brun
| > |
| > |
| > | Magestro Daniel wrote:
| > | >
| > | > 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:57 MET