EDM FAQ: Storable Objects

StorableObjects must ultimately inherit from the class StorableObject, must provide a number of virtual methods, and must implement some of these methods in a specific way.

A StorableObject has the following requirements:

• constructors, assignment, and clone() methods
• destructor, destroy(), and deallocate() methods
• ClassDef and ClassImp macros (defined by ROOT)
• a linkdef file (one per class)
• class_name and class_version methods
• a Streamer method
• a print method
• a postread method
• a prewrite method

Two methods appear in the base class StorableObject but are no longer used: activate() and deactivate(). Child classes need not implement these as they are never called.

While this list of requirements is rather long and complicated, there are many examples of StorableObject classes to explore in the EdmObjects package. All the "Toy" classes demonstrate common class design choices similar to actual CDF Offline objects.

All StorableObjects are characterised by a few properties that can be used in searches within an event.

• class name - The C++ class name of the object.
• object id - A unique integer assigned to an object by the event once an object is stored in the event.
• rcp id - A unique label identifying the creating module and module parameters for each object. The RCP system is not fully integrated into CDF Offline as yet.
• description string - A text string. There is no limitations on how these description strings are utilized or formatted, nor is their uniqueness guaranteed. Description strings can be thought of an unregulated cache for information that will eventually be extractable with an rcp id.

Comments on this page may be sent to Rob Kennedy