[ntuple] Initial minimal support for SoA I/O#21647
Open
jblomer wants to merge 14 commits intoroot-project:masterfrom
Open
[ntuple] Initial minimal support for SoA I/O#21647jblomer wants to merge 14 commits intoroot-project:masterfrom
jblomer wants to merge 14 commits intoroot-project:masterfrom
Conversation
Test Results 22 files 22 suites 3d 11h 59m 12s ⏱️ For more details on these failures, see this check. Results for commit 5985bf0. ♻️ This comment has been updated with latest results. |
hahnjo
reviewed
Mar 23, 2026
Member
hahnjo
left a comment
hahnjo
left a comment
There was a problem hiding this comment.
Thanks, I made a first pass over the PR and left some comments. Two "random" thoughts:
- Because
RSoAFielddoesn't support reading at the moment, the user is required to impose a model (if a top-level field), or even required to use views (if inside a member). This will be lifted eventually. - It is probably possible (I didn't see a check against it) to have a
classinherit from a base class that is annotated withrntupleSoARecord. At first I thought this might cause problems, but maybe it's fine? Do we want to allow this?
Add a new dict option to the LinkDef class pragma parser and the genreflex XML parser. When this option is set, the dictionary of the class has the rntuple.SoARecord attribute set to the type name of the record that underlies the SoA collection. This option and enforcing RNTuple streamer mode are mutually exclusive. fixup
Add EnsureValidUserClass() internal utility function that checks if a TClass represents a valid RNTuple user class. These checks are used by the RClassField and will be used later by the RSoAField.
Add SoA flag to field descriptor flags as well as a description of the treatment of SoA collections.
First implementation of a SoA field. This implementation supports only writing, no reading. Written data can be read though as collection of the underlying record type. Other limitations that will be lifted in follow-up commits: - support for inheritance - support for automatic schema evolution - support for class rename rules - support for SoA layout of inner structs
Contributor
Author
|
Good point on the inheritance. I didn't think about it but I don't think we need to forbid it, given that we already have classes that inherit from |
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
2 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.
First step towards SoA I/O in RNTuple. This PR lays the groundwork:
Tin SoA layoutUse of the SoA field is experimental at this stage and RNTuple will warn.
Part of #19230