Project

General

Profile

Feature #11495

FindMany/One interface that works with art::Ptr

Added by Kanika Sachdev over 3 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Navigation
Target version:
-
Start date:
01/26/2016
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
NOvA
SSI Package:
art
Duration:

Description

If I have an art::Ptr and want to access an object or a collection of objects associated with it, currently, I first have to make an art::PtrVector with that single object in it, and call FindMany/FindOne on that art::PtrVector.

It would be nice to have interfaces to FindOne, FindMany, FindManyP and FindOneP that return object/s associated with a single art::Ptr, instead of requiring a collection of them.


Related issues

Is duplicate of art - Feature #2536: FindOne/FindMany for a single input objectClosed10/03/2013

History

#1 Updated by Christopher Green over 3 years ago

  • Is duplicate of Feature #2536: FindOne/FindMany for a single input object added

#2 Updated by Christopher Green over 3 years ago

  • Category set to Navigation
  • Status changed from New to Rejected
  • SSI Package art added
  • SSI Package deleted ()

Per issue #2536 (released with art 1.08.09), we implemented support for C++11 initializer lists, viz:

FindOne<B> myBs( { myAPtr }, e, tag);
You therefore do not need to create a temporary PtrVector for one, or even several, Ptr objects.

Please let us know if you encounter any problems with this interface.

#3 Updated by Christopher Backhouse over 3 years ago

Well, the problem was never that this is impossible or inefficient, just that it's not very elegant, even with the PtrVector creation inlined into the call.

I suppose the solution on our side is to add a wrapper function something like:

template<class A, class B> Ptr<B> FindOneP(Ptr<A> aPtr, Event& evt, InputTag tag)
{
  return FindOneP<B>({aPtr}, evt, tag).at(0);
}

so the user can simply write

Ptr<B> bPtr = FindOneP<B>(aPtr, evt, tag);

Possibly (probably) the function name should be changed to not be unnecessarily confusing with the FindOneP class.

Would it be better to just add that to core art though? It's a shame to have wrappers when the underlying API could be friendlier in the first place.

#4 Updated by Christopher Green over 3 years ago

I should add an important note here: FindOne and FindMany, being smart query classes, are expensive to construct but very cheap to use. You should try to collect all the items you wish to study the associations for from the same Assns, and make a single FindOne / FindMany object if you can. Using a single Ptr as a reference for an association query should therefore, as a matter of efficiency, be quite rare.



Also available in: Atom PDF