-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store the collection information in a struct instead of a tuple #711
base: master
Are you sure you want to change the base?
Conversation
b24478c
to
de2fb09
Compare
The format for RNTuple has changed quite a bit with these changes, but I have no implemented anything yet to handle the older format transparently. This is mainly because I think it's not necessary yet, since I don't think there is any actual data stored in RNTuple yet. |
de2fb09
to
f746329
Compare
Not adding backwards compatibility for the RNTuple backend breaks the EDM4hep backwards compatibility tests, because those actually have been written with podio v1.2 and still use the old format. |
After these changes the storage details look like the following. The main differences is that the RNTuple version has one additional field TTree
RNTuple
|
Makes it possible to drop the collection id table storage
f746329
to
57c6a21
Compare
BEGINRELEASENOTES
struct
instead of using atuple
to facilitate access for non podio based backends (e.g. Julia)podio_metadata
TTree / Model as avector<podio::root_utils::CollectionWriteInfo>
, which contains all the necessary information for reading a collection.CollectionIDTable
is no longer written separately.ENDRELEASENOTES
Fixes #705
@peremato This addresses the TTree part of the problem. I just realized that RNTuple stores this in several vectors that run in parallel. I suppose it would be easiest for you (and also for us) to have similar layouts for TTree and RNTuple?