Skip to content

Conversation

@silverweed
Copy link
Contributor

This Pull request:

Draft PR for the RNTuple Attributes prototype.
This prototype allows writing, reading and merging TFile-based RNTuples containing Attributes. Note that the implementation is not final and cuts several corners in order to provide a proof of concept.

Note that this new optional feature requires the Binary Format to be bumped by one minor version.

@silverweed silverweed requested review from enirolf, hahnjo and pcanal June 24, 2025 12:41
@silverweed silverweed self-assigned this Jun 24, 2025
@github-actions
Copy link

github-actions bot commented Jun 25, 2025

Test Results

    16 files      16 suites   3d 4h 16m 26s ⏱️
 3 650 tests  3 648 ✅ 0 💤 2 ❌
57 056 runs  57 054 ✅ 0 💤 2 ❌

For more details on these failures, see this check.

Results for commit 565836e.

♻️ This comment has been updated with latest results.

@silverweed silverweed force-pushed the ntuple_attr branch 3 times, most recently from 3aa19c0 to b3b4900 Compare July 2, 2025 11:19
@silverweed silverweed force-pushed the ntuple_attr branch 5 times, most recently from e77589e to b86c122 Compare July 11, 2025 11:47
@silverweed silverweed force-pushed the ntuple_attr branch 6 times, most recently from 658dcd2 to 7fc58aa Compare July 22, 2025 13:31
@silverweed silverweed added the clean build Ask CI to do non-incremental build on PR label Jul 22, 2025
@silverweed silverweed closed this Jul 22, 2025
@silverweed silverweed reopened this Jul 22, 2025
@silverweed silverweed force-pushed the ntuple_attr branch 2 times, most recently from 0a24d9c to 0dcc555 Compare July 25, 2025 07:25
@silverweed silverweed force-pushed the ntuple_attr branch 2 times, most recently from ed882c4 to 49f5abc Compare August 8, 2025 09:58
silverweed and others added 26 commits September 4, 2025 08:53
- RNTupleAttributeSetReader -> RNTupleAttrSetReader
- RNTupleAttributeSetWriter -> RNTupleAttrSetWriter
- RNTupleAttributeEntry -> RNTupleAttrEntry
Attribute Entries are now created on the user side similarly to what
happens with the main data. So instead of having:

auto attrEntries = attrSet->GetAttributes(0);

you now do:

auto attrEntry = attrSet->CreateAttrEntry();
attrSet->LoadAttrEntry(0, attrEntry);

This means that the attribute entry can be reused instead of having to
recreate it every time.
We always merge AttributeSets in Union mode and we use the same
Error Behavior as the main RNTuple.
The new API more closely resembles the main RNTuple API. Now, instead
of having BeginRange() allocate the AttributeEntry every time, it
returns a "pending range" which can then be used to commit a REntry
which can be created from the attribute user model, or it can even be
the user model's default entry.
We don't use any more the RNTupleAttrEntry but rather just regular
REntries. This allows more flexibility as the user can decide whether to
create their own entry or use the default entry from the reader.
LoadAttrEntry() now returns the Range information.
for consistency with RNTupleWriter::Recreate, pass the model first and
the name second.
...since Append() was made private
To avoid conflicts if the user names the attribute set like one of the
internal names
This can be useful to store it in collections etc. Since we already
allow moving from a PendingRange, we already need to handle an "invalid
state" anyway, so it makes sense you can default construct a value in
the invalid state.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clean build Ask CI to do non-incremental build on PR in:RNTuple

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants