additions for embedding - #15836
additions for embedding#15836nzardosh wants to merge 2 commits into
Conversation
| O2HASH(#_BaseName_); \ | ||
| O2HASH("Stored" #_BaseName_); \ | ||
| O2HASH("Stored" #_BaseName_); \ | ||
| O2HASH("StoredEMB" #_BaseName_); \ |
There was a problem hiding this comment.
Why is this needed? Since StoredBaseName is already declared, you can use StoredBaseNameFrom<> for it.
There was a problem hiding this comment.
but that is for origin AOD1 isnt it? what if you want 3 versions of a table with AOD, AOD1 and EMB as origins?
There was a problem hiding this comment.
In principle, with the new ability to set the origin explicitly, the staged declaration is not really needed. From<EMB> is the same as From<AOD1>. Instead of declaring several types, this should be reworked into declaring a single type and predeclaring its aliases with AOD1 and EMB origins, for example.
There was a problem hiding this comment.
ok I will remove it then
| template <aod::is_origin_hash O> | ||
| using TracksExtraFrom = TracksExtra_002From<O>; |
There was a problem hiding this comment.
Is this needed for all tables which use the new feature?
If yes, @aalkin could it be added to the table declaration macro?
There was a problem hiding this comment.
The plan is to make this a part of the table declaration macro eventually, however, it would be much more involved, than just adding an alias. I am trying to find a way to avoid having to break the declarations in O2Physics.
This branch has not been deployed
4 participants
PR needed for the use of embedding in O2Physics
@aalkin might be worth adding the "From" templating to all tables in the datamodel in the future for any users needing to access them with a different origin?