[ntuple] Attributes: update specs and add de/serialization #19894
Conversation
Test Results 21 files 21 suites 3d 16h 43m 57s ⏱️ For more details on these failures, see this check. Results for commit 6c3a26f. ♻️ This comment has been updated with latest results. |
silverweed
force-pushed
the
ntuple_attr_1
branch
2 times, most recently
from
b0449c0 to
48b72ff
Compare
|
I updated the PR and uniformed the |
silverweed
force-pushed
the
ntuple_attr_1
branch
from
48b72ff to
07b8b20
Compare
silverweed
force-pushed
the
ntuple_attr_1
branch
from
07b8b20 to
6c3a26f
Compare
| 1. it cannot have linked Attribute RNTuples itself; | ||
| 2. the Alias columns sections, both in its header and footer, must be empty (i.e. none of the Attribute Set RNTuple's | ||
| Fields can be Projected Fields); | ||
| 3. none of its fields may have a structural role of 0x04 (i.e. it must not contain a ROOT streamer object); |
There was a problem hiding this comment.
Is it a choice or a technical limitation?
| An Attribute Set RNTuple has a number of restrictions compared to a regular RNTuple: | ||
|
|
||
| 1. it cannot have linked Attribute RNTuples itself; | ||
| 2. the Alias columns sections, both in its header and footer, must be empty (i.e. none of the Attribute Set RNTuple's |
There was a problem hiding this comment.
Is there (somewhere else) a more detailed explanation/reason for this limitation?
|
|
||
| ### Attribute Schema Version | ||
| Each Attribute Set is created with a user-defined Model. This Model is not used directly by the underlying Attribute | ||
| Set RNTuple, but it is augmented with internal fields used to store additional data that serve to associate each |
There was a problem hiding this comment.
When inspecting the Attribute Set RNTuple will the additional fields be exposed or hidden? (And If they are exposed would a user be able to distinguish the implicit vs the explicit part of the model?)
| if (fnBufSizeLeft() < static_cast<int>(sizeof(std::uint64_t))) | ||
| return R__FAIL("record frame too short"); | ||
| std::uint16_t vMajor, vMinor; | ||
| bytes += DeserializeUInt16(bytes, vMajor); |
There was a problem hiding this comment.
Should there be a:
if (vMajor > 1)
throw;
and/or did I misunderstand:
A change in Major version number indicates a breaking, non-forward-compatible change in the schema: readers should
refuse reading an Attribute Set whose Major Schema Version is unknown.
and/or should that statement be weakened?
First PR of a series to merge the RNTuple Attributes into master. The final result will be this, although the commits will be reorganized to be more coherent and reviewable.
This first PR updates the binary format specification (introducing a new minor version) and updates the Serializer and Descriptor code to match. This is backward-compatible and no Attribute can be written yet since the writer API will be introduced later.
Checklist: