[ntuple] Support reading alternative types through the RNTupleProcessor#21462
Open
enirolf wants to merge 6 commits intoroot-project:masterfrom
Open
[ntuple] Support reading alternative types through the RNTupleProcessor#21462enirolf wants to merge 6 commits intoroot-project:masterfrom
RNTupleProcessor#21462enirolf wants to merge 6 commits intoroot-project:masterfrom
Conversation
enirolf
changed the title
RNTupleProcessorRNTupleProcessor
Test Results 22 files 22 suites 3d 4h 24m 18s ⏱️ For more details on these failures, see this check. Results for commit 2630d07. ♻️ This comment has been updated with latest results. |
enirolf
force-pushed
the
ntuple-processor-alternative-types
branch
from
ec4f94c to
091710b
Compare
silverweed
reviewed
Mar 4, 2026
| std::vector<RProcessorValue> fProcessorValues; | ||
| std::unordered_map<std::string, FieldIndex_t> fFieldName2Index; | ||
| // Maps from the field name to all type alternatives for that field that have been added to the entry. | ||
| std::unordered_map<std::string, std::unordered_set<FieldIndex_t>> fFieldName2Index; |
Contributor
There was a problem hiding this comment.
I'm not sure about using an unordered_set here: unless we expect hundreds of alternative types for a single field, a vector is probably gonna be much faster (especially if the most common case is a single element in it)
hahnjo
reviewed
Mar 10, 2026
enirolf
force-pushed
the
ntuple-processor-alternative-types
branch
from
091710b to
746a870
Compare
hahnjo
approved these changes
Apr 7, 2026
This changes requires moving the ownership of all fields from an internally stored `RNTupleModel` in each processor (`fProtoModel`) to the `RNTupleProcessorEntry`. Full removal of `fProtoModel` is taken car of in the next commit. This change also enables proper handling of subfields, for wich a test will be added in a separate commit.
To enable this, an additional prefix needed to be added to distinguish them internally from regular fields that have been added explicitly by the user.
This change also includes a different way to handle field/processor naming conflicts, which previously relied on the `fProtoModel`, plus an additional test for this
To make sure that fields of "second chains" are also added correctly to the processor.
enirolf
force-pushed
the
ntuple-processor-alternative-types
branch
from
746a870 to
2630d07
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This changes requires moving the ownership of all fields from an internally stored
RNTupleModelin each processor (fProtoModel) to theRNTupleProcessorEntry. In turn, potential namin conflicts when auxiliary RNTuples in a join have the same name as a field in the primary RNTuple are now also handled differently, since this used to rely on thefProtoModel.This change implicitly adds proper support for requesting subfields, for which tests have been added.