Feature #5790

It should be possible to discover the art metadata for an object.

Added by Herbert Greenlee about 7 years ago. Updated over 3 years ago.

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


Estimated time:
SSI Package:


It should be possible to discover the art metadata for a data product from only a bare pointer to the object (including an art data product should be able to discover its own art metadata from its own "this" pointer). By art metadata, I mean everything that gets stored in an art::Ptr besides the c++ pointer. Here's the main use case: It should be possible to discover associated objects (art::Assns) for an object that is only known from a bare c++ pointer (including an object should be able to discover own associated objects).

If there is a way to do this now, I would like to know that too.


#1 Updated by Christopher Green about 7 years ago

  • Category set to Navigation
  • Status changed from New to Feedback
  • Experiment MicroBooNE added
  • Experiment deleted (-)
  • SSI Package art added
  • SSI Package deleted ()

If you have a bare pointer to an element of a container, you have already stripped away anything that could possibly answer your question. art::Handle::provenance() will get you what you want, so you must cache the art::Handle yourself and pass it around as necessary. Having an art::Ptr to a collection element will get you (in a slightly convoluted and not-intended-to-be-easy fashion) access to an art::ProductProvenance object, which will give you some of the metadata for the object, but not everything the Handle could show you. Unwrapped data products ("bare pointer to a product," as you said) and entries in a collection are entirely user-defined -- there's no way we could provide an interface or require they be able to do anything in particular.

Technically speaking (because everything is possible in software) we could provide the system you asked for by keeping track of every product and the address of every element in every product which is a collection (std::list elements are non-contiguous, just for starters, and there's no reason a data product can't be or contain a list). It would be expensive to create, expensive to carry around in memory and expensive to use, and almost certainly still put constraints on the data product designer to provide a translation service.

Please let us know whether you want to continue with this request. We can discuss it at an upcoming stakeholders meeting if you wish.

#2 Updated by Rob Kutschke about 7 years ago

For what it's worth, I am moving towards a pattern in which I pass handles (by ref) down the call stack. If I want to do anything "expensive" with the handle I deference it once and pass around the bare pointer/reference; but I make that decision locally, not globally. I also make a judgement that certain low level utilities should see only the bare data product - but that boundary is really a judgement call and will sometimes be wrong, necessitating a breaking fix

#3 Updated by Kyle Knoepfel about 6 years ago

  • Target version set to 521

#4 Updated by Kyle Knoepfel over 3 years ago

  • Target version deleted (521)

Also available in: Atom PDF