TTree incorrectly run I/O customization rules on "new" data members. #9899
Comments
pcanal
added a commit
to pcanal/root
that referenced
this issue
Feb 16, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix root-project#9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
pcanal
added a commit
to pcanal/root
that referenced
this issue
Feb 18, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix root-project#9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
|
Hi @pcanal, It appears this issue is closed, but wasn't yet added to a project. Please add upcoming versions that will include the fix, or 'not applicable' otherwise. Sincerely, |
pcanal
added a commit
that referenced
this issue
Feb 18, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix #9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
pcanal
added a commit
that referenced
this issue
Feb 18, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix #9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
pcanal
added a commit
that referenced
this issue
Feb 18, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix #9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
pcanal
added a commit
that referenced
this issue
Feb 18, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix #9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
pcanal
added a commit
to pcanal/root
that referenced
this issue
Oct 4, 2022
This resolved the problem seen at: cms-sw/cmssw#36908 (comment) and fix root-project#9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As reported at: cms-sw/cmssw#36908 (comment)
The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a "new" member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case.
The text was updated successfully, but these errors were encountered: