Athena Developer Guide

Athena Chapter 15 Converters Version/Issue: 2.0.0
i. “Macroscopic” references appear as separate “leaves” in the data store. They have to be
registered with a separate opaque address structure in the data directory of the object being
converted. This must be done after the object was registered in the data store in the method
fillObjRefs().
ii.
Internal references must be handled differently. There are two possibilities for resolving
internal references:
1. Load on demand: If the object the reference points to should only be loaded when
accessed, the pointer must no longer be a raw C++ pointer, but rather a smart pointer
object containing itself the information for later resolution of the reference. This is
the preferred solution for references to objects within the same data store, e.g.
references from the Monte-Carlo tracks to the Monte-Carlo vertices. Please see in
the corresponding SICB converter implementations how to construct these smart
pointer objects. Late loading is highly preferable compared to the second possibility.
2. Filling of raw C++ pointers: Here things are a little more complicated and introduces
the need for a second step in the process. This is only necessary if the object points
to an object in another store, e.g. the detector data store. To resolve the reference a
converter has to retrieve the other object and set the raw pointer. These references
should be set in the fillObjRefs() method. This of course is more complicated,
because it must be ensured that both objects are present at the time the reference is
accessed (i.e. when the pointer is actually used).
15.5 Converter implementation - general considerations
page 142
After covering the ground work in the preceding sections, let us look exactly what needs to be
implemented in a specific converter class. The starting point is the Converter base class from which
a user converter should be derived. For concreteness let us partially develop a converter for the UDO
class of Chapter 7.
The converter shown in Listing 15.1 is responsible for the conversion of UDO type objects into objects
that may be stored into an Objectivity database and vice-versa. The UDOCnv constructor calls the
Converter base class constructor with two arguments which contain this information. These are the
values CLID_UDO, defined in the UDO class, and Objectivity_StorageType which is also
defined elsewhere. The first two extern statements simply state that these two identifiers are defined
elsewhere.
All of the “book-keeping” can now be done by the Converter base class. It only remains to fill in the
guts of the converter. If objects of type UDO have no links to other objects, then it suffices to implement
the methods createRep() for conversion from the transient form (to Objectivity in this case) and
createObj() for the conversion to the transient form.
If the object contains links to other objects then it is also necessary to implement the methods
fillRepRefs() and fillObjRefs().