Make FindOne<ProdB> work whether the association was made with or without metadata
We have a feature request about association. Currently if an association was made without metadata, we need to do the following to retrieve it
FindOne<ProdB>(Handle<ProdAColl> const &, Event const &, InputTag const &);
If the association was made with metadata, we need to do the following:
FindOne<ProdB, Data>(Handle<ProdAColl> const &, Event const &, InputTag const &);
It would be convenient if
FindOne<ProdB> can be used to get association made with metadata. Of course the metadata will be ignored in this case.
Here is one user case. We plan to make hit-track association with metadata. But there is a lot of code in larsoft that retrieve hit-track association through
FindMany without specifying metadata. If the above feature is implemented, we do not need to change the existing code to make it work with the new association.
#1 Updated by Christopher Green about 5 years ago
- Tracker changed from Support to Feature
- Category set to I/O
- Status changed from New to Accepted
- Estimated time set to 40.00 h
- SSI Package art added
- SSI Package deleted (
This is an eminently sensible request, and we have a sketched-out conceptual solution.
#2 Updated by Christopher Green about 4 years ago
- Description updated (diff)
- Status changed from Accepted to Feedback
- Assignee set to Christopher Green
- Target version set to 2.06.00
- Experiment LArSoft added
- Experiment deleted (
During the preliminary analysis of this issue, we have a couple of scenarios (thus far) that might cause ambiguity when reading older files:
L1 writes an
art::Assns<A, B> with instance name
I1 in process
X, while in later process
Y, a module also labeled
L1 writes an
art::Assns<A, B, D> with instance name
I1. What happens if a subsequent module in the same or a later process requests an
Assns<A, B> with input tag
L1:I1, either directly, or via a request for a
Our preferred resolution of this ambiguity would be that the data product from process
Y would be selected. However, this is a change in behavior from previous and current versions of art, where the data product from process
X would be selected.
L1 in process
X writes an
art::Assns<A, B> with instance name
I1, and an
art::Assns<A, B, D> with the same instance name,
I1. If a subsequent module in the same or a later process requests an
Assns<A, B> with input tag
L1:I1 (directly or otherwise), what should happen?
Our preferred resolution of this question would be that the
art::Assns<A, B> would be selected at the expense of the
art::Assns<A, B, D>. This is in fact the same behavior as previous and current versions of art.
Please let us know whether the suggested solutions are acceptable to you. Note that other behaviors could be programmed, including the testing for and warning of the conditions above. It's possible that the tests required might add an overhead over and above the default behavior, however.
#3 Updated by Tingjun Yang about 4 years ago
Thanks for the suggested solutions. They sound good to me but I would like larsoft experts (e.g. Gianluca) to comment on this.
To me, if some code is requesting Assns<A,B>, it would make sense to return Assns<A,B>, if that is not available, return Assns<A,B,D>. If neither is available, throw an error.
#4 Updated by Christopher Green about 4 years ago
Gianluca has been added to the watch list, and we will explicitly request his input via email.
For us, the biggest worry is that we get consistent matching behavior when products are in the same file but different processes. We feel that someone putting an
Assns<A, B, D> into the event could reasonably expect it to supersede an earlier
Assns<A, B>. The simple rule would be that a match from the current process is returned when available; the requested behavior is for an
Assns<A, B, D> to match when an
Assns<A, B> is called for, and special cases tend to lead to complications and erroneous assumptions.
#5 Updated by G2Muon G2Muon about 4 years ago
About the previous comment - my recommendation is that if there are two candidates, distinguished only by process name, then the behaviour should be to require a process name or throw an exception. I would not try to guess which of the other solutions others might think is the natural default.
#7 Updated by Marc Paterno about 4 years ago
The standard procedure to find a product, when a process name is not provided, looks at the product type and the specified module label (and instance name if provided). If exactly one matching product is found "in the current process" (which means produced by a module in the current process), it is returned. If there is more than one matching product, an exception is thrown. If there are no matching products, then the process history is consulted, and we effectively walk back in time through earlier processes, looking for a process in which there is one match (yielding success) or in which there are multiple matches (again, an exception throw). If no matching product is found in any process, the result is an exception (if
getValidHandle is being used) or an invalid
getByLabel is being used).
If a process name is provided, then only that process is searched.
The documentation in the workbook is consistent with this, but does not describe the whole issue; I believe it is a later planned-but-not-written exercise that would go into these details. The details are most important in re-reconstruction scenarios.
#8 Updated by Rob Kutschke about 4 years ago
I intended my initial comment to be limited to a request for an ambiguously specified data type - not as a request for a change to the present behaviour for all requests. I see now that I did not make that clear.
Suppose I have a file with
Assns<A,B,D> current process
Assns<A,B> older process
What should happen on a request for Assns<A,B> with no process name specified? Did I mean that I want any product usable as Assns<A,B> with the usual rules about the current process being the default? Or did I mean that I want the type Assns<A,B> exactly, without regard to process name.
Because art has no way of knowing which request you meant, it should throw an exception.
On the other hand, if the event contains only one of these two data products, then there is no ambiguity and art can return an answer.
Or do you consider this creating a special case?
#9 Updated by Marc Paterno about 4 years ago
Our proposal is for the case you describe:
Assns<A,B,D> created in the current process
Assns<A,B> product in the input file, as it must be if created in an older process
would be that a lookup of
Assns<A,B> would find the
Assns<A,B,D>, because it would be considered "a match". This is a change in behavior, because currently that is not considered as a match.
This is like all current behavior in one way, and unlike in another. It is like current behavior because it is returning the match from the most recent process in which one is found. It is unlike current behavior in that the match is not for an identical type. However, since
Assns<B,A> is a different C++ type than
Assns<A,B>, yet satisfies the same lookup, it is already the case that the lookup rules for
Assns are special. We are proposing an extension of the specialness, to include a lookup of
Assns<A,B> matching an object of type
#10 Updated by Gianluca Petrillo about 4 years ago
Reading through, I can't find a reference to what happens on a request of
art::Assns<A, B> when only
art::Assns<A, B, D1> and
art::Assns<A, B, D2> with the same input tag are available from the same process.
I would assume an exception will be thrown.