root icon indicating copy to clipboard operation
root copied to clipboard

[ntuple] Handle missing values in RNTupleProcessor

Open enirolf opened this issue 6 months ago • 1 comments

When an entry managed by the RNTupleProcessor contains missing data for certain fields, for example because they are missing in a subsequent chain or auxiliary ntuple, we need a way to signal to the user that the resulting entry has missing data and is therefore invalid.

The RNTupleProcessorValuePtr, together with the RNTupleProcessorEntry (which is a thin wrapper around REntry) capture this requirement by only returning actual data if the entry is marked as "valid" by the processor. Its use can be seen in action in the MissingEntries test in ntuple_processor_join.cxx.

With the addition of RNTupleValuePtr, pointers to the values of an RNTupleModel's default entry, returned by e.g., MakeField should not be used together with the RNTupleProcessor anymore, because they may contain incorrect data. More specifically, when a particular field's data could not be loaded for a certain entry, it will retain its previous value. The RNTupleValuePtr adds appropriate checks for this, but to prevent users from using pointers returned from a model's default entry, we only allow RNTupleProcessors to be created from bare models.

Finally, this PR changes the iterator provided by the RNTupleProcessor from the full entry to only the (global) entry index. Providing the full entry was already a bit questionable, because it would allow users to call GetPtr or related functions inside of the loop, which we want to avoid. Other than that, there is (currently) no additional useful information one can obtain from the full entry.

enirolf avatar Jun 02 '25 14:06 enirolf

Test Results

    19 files      19 suites   3d 17h 5m 4s ⏱️  2 803 tests  2 803 ✅ 0 💤 0 ❌ 51 757 runs  51 757 ✅ 0 💤 0 ❌

Results for commit 389a1cc5.

:recycle: This comment has been updated with latest results.

github-actions[bot] avatar Jun 02 '25 22:06 github-actions[bot]

Closing this as it has been superseded by #19111.

enirolf avatar Jun 20 '25 09:06 enirolf