Skip to content

SGTools: Fix interaction between forward-declared links and symlinks.

Scott Snyder requested to merge ssnyder/athena:linkfwd.SGTools-20230824 into main

Suppose we have a class B with a derived class D. We have some object that has a DataLink to the base class B. We go ahead and create this DataLink, giving just the name; the object itself doesn't exist yet. We'll create a DataProxy to represent this object, which will be of type B.

Then later, we create the referenced object, which is of actual type Derived. When we record this in SG, we'll make a new proxy, with type Derived. But StoreGate will then try to make a symlink for the base class Base. But that then fails because the first proxy is already there.

Try to allow this: if we're adding a symlink and there's an existing proxy that does not yet have an object set, we check to see if the type of the new object derives from the type of the existing proxy. If so, then we set the data object for the existing proxy to that object.

This does mean that we can end up with two proxies then referencing the same object. The data objects themselves are refcounted, so there won't be memory management issues. However, we need to be careful so that registry() for the object remains pointing at the proxy describing its actual type; otherwise, the clid written in the DataHeader will be wrong.

A concrete example of this is creating an xAOD facade object and setting the store pointer to a DataLink to a not-yet-created auxililary store object.

Merge request reports