Feature #11495

FindMany/One interface that works with art::Ptr

Added by Kanika Sachdev about 5 years ago. Updated about 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


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


#1 Updated by Christopher Green about 5 years ago

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

#2 Updated by Christopher Green about 5 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 about 5 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 about 5 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