Skip to content

[ntuple] Attributes: add support for writing#21289

Open
silverweed wants to merge 6 commits intoroot-project:masterfrom
silverweed:ntuple_attr_write
Open

[ntuple] Attributes: add support for writing#21289
silverweed wants to merge 6 commits intoroot-project:masterfrom
silverweed:ntuple_attr_write

Conversation

@silverweed
Copy link
Contributor

This Pull request:

adds the RNTupleAttrSetWriter class and initial support for writing attributes. This involves touching, among other classes, the RNTupleWriter, RNTupleFillContext, RPageSink and RMiniFile.

Original reference PR (now quite outdated): #19153

Checklist:

  • tested changes locally
  • updated the docs (if necessary)

@github-actions
Copy link

github-actions bot commented Feb 16, 2026

Test Results

    18 files      18 suites   2d 16h 49m 45s ⏱️
 3 796 tests  3 795 ✅ 0 💤 1 ❌
61 588 runs  61 587 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 505da84.

♻️ This comment has been updated with latest results.

@silverweed silverweed added the clean build Ask CI to do non-incremental build on PR label Feb 18, 2026
@silverweed silverweed force-pushed the ntuple_attr_write branch 4 times, most recently from 16e0a45 to 9b598df Compare February 23, 2026 10:05
Copy link
Member

@hahnjo hahnjo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A first review... I think one high-level decision to make is where to build RNTupleAttrSetDescriptor. RNTupleFileWriter feels like the wrong place to do this.

Comment on lines +8 to +9
#ifndef ROOT7_RNTuple_Attributes
#define ROOT7_RNTuple_Attributes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A while ago, we started having one header per class. I think we should keep this pattern and split the header RNTupleAttributes.hxx proposed here

Copy link
Contributor Author

@silverweed silverweed Feb 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still have some exceptions where it makes sense (RNTupleDescriptor.hxx, RNTupleUtils.hxx, ...); I'm not sure that splitting this would bring much value - perhaps the splitting could be made at the reading vs writing level?

Comment on lines +50 to +56
inline const char *const kRangeStartName = "_rangeStart";
inline const char *const kRangeLenName = "_rangeLen";
inline const char *const kUserModelName = "_userModel";

inline constexpr std::size_t kRangeStartIndex = 0;
inline constexpr std::size_t kRangeLenIndex = 1;
inline constexpr std::size_t kUserModelIndex = 2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are (currently) not used in the header and should probably be moved to the implementation file, where needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these will be used by tests in a later PR - should I move them now and then move them back later?

Comment on lines +58 to +59
inline const std::uint16_t kSchemaVersionMajor = 1;
inline const std::uint16_t kSchemaVersionMinor = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these move into the RNTuple class where we have the other constants such as kVersionEpoch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly; though these only concern attributes so it's not necessarily interesting for users of the RNTuple class. It's a matter of deciding whether we want to centralize these binary specs-related constants or not.
I have no strong opinion either way.

Comment on lines 8 to 9
ROOT::TestSupport::CheckDiagsRAII diagsRaii;
diagsRaii.requiredDiag(kWarning, "ROOT.NTuple", "RNTuple Attributes are experimental", false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this should already be there in the previous commit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The warning only triggers when the attribute set is committed, so this wouldn't show up until Commit() is implemented

@silverweed
Copy link
Contributor Author

Thanks for the thorough review @hahnjo! For the descriptor building I agree it feels weird to have it in the Writer; let's talk about it offline.

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