ROOT PPP 03.09.2026

• [Stephan]: Are the RNTupleProcessor classes polymorphic?

  • Yes

• [Stephan]: when you create a combined processor, do you need to give ownership of the input processors to the combined one?

  • Yes, all constructors accept std::unique_ptr. This is done to avoid inconsistencies while processing events (the driver of the loop is the "main" processor (i.e. the leftmost one in the combination)).

• [Martin]: How many columns can you join on?

  • Up to four

• [Philippe]: Do you have a clone/copy mechanism?

  • Not yet

• [Philippe]: The current processor number, or the equivalent in TChain is used for two completely different purposes: one is to detect a file transition, the other is to know which is the current file if the user want to do something different depending on that.

  • For the first case, that's an internal thing now and doesn't need to be public, the second one could be a use case
  • [Jakob] but the underlying item is not a file now, it's another processor, so the semantics are unclear.

• [Philippe] what is the difference between GetCurrentEntryNumber and GetNEntriesProcessed?

  • For now, nothing. But for example in MT scenarios they could be different
  • [Vincenzo] or also if we allow sparse reading

• [Jakob] I think we should start with all private interfaces except those for which we have evidence that it's necessary

• [Philippe]: Having to advance an iterator for a million events is more expensive than the user telling us they want to go to entry one million, in the latter case we can just skip entire files.

• [Jakob/Stephan]: Maybe not loading random entries but advancing by more than one entry sounds like an important feature.

  • [Stephan] your iterator could accept an integer such that calling std::advance on it could make it jump by that number.

• [Vincenzo]: What happens with BindRawPtr?

  • This introduces some unsafety.
  • [Vincenzo]: could we also have a std::shared_ptr interface?
  • [Jonas]: depends on what use case we want to cater, shared_ptr may have some benefit

• [Vincenzo]: how thorough is the tracking of fields in the datasets of the internal RNTupleProcessorEntry? For example, I have two chains and I join them together. A certain column x is present now in a file of the left chain and then in a file of the right chain

  • [Philippe] the use case defined above may actually exist, we have seen this in TTree.
  • [Vincenzo] I believe with a carefully crafted set of join and chain combinations, this could work with the RNTupleProcessor but only if we relax the requirement of the auxiliary dataset prefix
  • [Florine] I'll get to that later, but also I don't like anything about this use case.
  • [Jakob] I would at least note it down, maybe it's an advanced use case but doesn't sound completely crazy to me.

• [Stephan]: naming of the kUseAuxPrefix flag, maybe we can change it to something more clear to users

  • Like kRequireAuxPrefix
  • [Jonas] For example kLazyNameMatching

• [ Jonas] coming back to that situation above, should we check in all processors or just in the first set?

  • Currently it checks only in the first RNTuple, maybe we can add a deep search?
  • [Jonas] I'm worried about the fact that if you specify the prefix, for that case the order doesn't matter
  • [Jakob] Couldn't we have something like an alias definition or a rename definition? For this particular processor instance, that field is called something else
  • Whats the benefit?
  • [Jakob] I'm wondering if we could have a more general interface that lets us as a side effect disambiguate better.
  • [Stephan] I don't see how the renaming would make things safer.
  • [Jakob] For these advanced use cases, we should avoid designing API such that it forbids the use case altogether.

• [Stephan] Checking name conflicts sounds like you have to check the entire chain a priori, can you do it on file change?

• [Vincenzo] I wanted to ask for a clarification about the use case, my understanding is this is done for when the user expects a certai column name to be there, irrespectively of whether there are multiple joins, or whether there was a previous processing that led to merging fields and having one RNTuple on disk with the column already available

  • Yes

• [Jonas] For final point 4, that also includes persistifying join table?

  • At some point, it's a separate point I didn't include.
  • [Philippe] persistifying the table is "trivial"
  • Not sure if it is