[ntuple] Add RPageSinkFile::CloneWithDifferentName #21063
Conversation
Test Results0 tests 0 ✅ 0s ⏱️ Results for commit fa2b7b6. ♻️ This comment has been updated with latest results. |
silverweed
force-pushed
the
ntuple_sink_clone
branch
from
b2d8186 to
d1b6b48
Compare
Do we also need to support the case where the user would like to clone in a different directory (and/or is it mostly for internal use)? |
It's for internal use only (for the Attributes) and we always want to write to the same directory |
silverweed
force-pushed
the
ntuple_sink_clone
branch
from
d1b6b48 to
88f3c3a
Compare
| ~RNTupleFileWriter(); | ||
|
|
||
| /// Creates a new RNTupleFileWriter with the same underlying TDirectory as this but writing to a different | ||
| /// RNTuple named `ntupleName`. This class is not thread safe, so one of the two writers may be writing to the file |
There was a problem hiding this comment.
I think the point is not so much that the class is not thread-safe (because we create to separate objects). It's more that both classes operate on the same underlying file resource.
There was a problem hiding this comment.
But writing to the same file simultaneously is only a problem is you do it in parallel, no?
There was a problem hiding this comment.
Yes, that's right. It's a nit anyway, feel free to resolve this.
Writing analogue to RPageSourceFile::OpenWithDifferentAnchor, it allows to derive a new Sink from an existing one using the same underlying directory but writing to a different RNTuple.
silverweed
force-pushed
the
ntuple_sink_clone
branch
from
88f3c3a to
fa2b7b6
Compare
3 participants
Last part of #19904.
Adds a writing analogue to RPageSourceFile::OpenWithDifferentAnchor, which allows to derive a new Sink from an existing one using the same underlying directory but writing to a different RNTuple.
Was previously called
DeriveForbut I found the name too obscure and I think this is clearer.Checklist: