[ntuple] DAOS object class customization (2/2): provide RNTupleWriteOptionsDaos#8452
Conversation
|
Starting build on |
mxxo
left a comment
mxxo
left a comment
There was a problem hiding this comment.
Hey Javier, just looking at the write options changes everything looks good. It looks like you've been very careful to make potential null dereferences of fOptions impossible. I believe this is the first time dynamic_cast is used in RNTuple, is that is a milestone?
jblomer
left a comment
jblomer
left a comment
There was a problem hiding this comment.
Very well! One tiny comment.
|
Starting build on |
|
Build failed on mac11.0/cxx17. Errors:
|
|
Build failed on ROOT-debian10-i386/cxx14. Errors:
|
|
Build failed on windows10/cxx14. |
…<RNTupleWriteOptions>` Using a `std::unique_ptr<>` avoids object slicing in case `fOptions` points to an instance of a derived class. a derived
Move the `{Serialize,Deserialize}String` functions to the
`ROOT::Experimental::Internal::RNTupleSerialization` namespace where they may be
reused by other parts of RNTuple.
Use `OC_SX` (distribute among all targets) for OIDs that relate to ntuple metadata, e.g. header/footer.
Enable customizing the object class for user data OIDs via `RNTupleWriteOptionsDaos`.
…SF` -> `OC_SX` The `OC_SX` object class (i.e. distribute data among all targets) is probably a more reasonable default. This parameter can be changed per-ntuple via `RNTupleWriteOptionsDaos`.
jalopezg-git
force-pushed
the
ntuple-daos-oclass-impl
branch
from
d34d798 to
3fe5bbf
Compare
|
Starting build on |
4 participants
This pull-request is a follow-up of #8402.
RNTupleWriteOptionsDaos, i.e. a subclass ofRNTupleWriteOptions, may now be used to provide DAOS-specific options. Currently, we only support setting the object class used for user data OIDs.Changes or fixes:
RNTupleWriteOptionsmay carry additional options.ROOT::Experimental::Internal::RNTupleSerializationnamespace, where they can be reused.OC_SXis always used to store metadata (i.e. header/footer and anchor). The object class must be known to read the ntuple; thus, the object class name is stored in the anchor.OC_SX(before wasOC_RP_XSF).OC_SXdistributes data over all the targets and is probably a more sane default.This PR closes issue #8205.