Container id definitions for the columnar infrastructure. More...

#include <ContainerId.h>

Collaboration diagram for columnar::RegularContainerId< ObjectType, ContainerType >:

Public Types
using	xAODObjectIdType = const ObjectType
	the xAOD type to use with ObjectId
using	xAODObjectRangeType = const ContainerType
	the xAOD type to use with ObjectRange
using	xAODElementLinkType = ContainerType
	the xAOD type to use with ElementLink

Static Public Attributes
static constexpr bool	isContainerId = true
	identify this as a container id definition
static constexpr bool	regularObjectId = true
	whether to use the regular ObjectId/ObjectRange
static constexpr bool	variantObjectId = false
	whether to use a variant ObjectId
static constexpr bool	regularColumnAccessorArray = true
	whether to use a regular column accessor in array mode
static constexpr bool	isMutable = false
	whether this is a non-const container
static constexpr bool	perEventRange = true
	whether this can be retrieved as a range per event
static constexpr bool	perEventId = false
	whether this can be retrieved as a single object per event

Detailed Description

template<typename ObjectType, typename ContainerType>
struct columnar::RegularContainerId< ObjectType, ContainerType >

Container id definitions for the columnar infrastructure.

Container ids identify the different "virtual" containers used by the columnar infrastructure. Each container id is represented by a struct (typically named with a Def suffix, e.g. JetDef, ElectronDef, ParticleDef) that describes the container. These structs are defined directly in the columnar namespace and are used as template parameters throughout the columnar code. The user should not be trying to create instances of these structs, but rather use them as identifiers to pass into various columnar templates.

To first order there is one container id for each xAOD type, and there is a direct mapping from container id to xAOD type. And for your code to compile in xAOD mode, your objects will be represented by a pointer to the underlying xAOD type. So to make your code compile in xAOD mode, you need to use the container id that corresponds to the xAOD type you want to use.

In the columnar world we don't really have objects like that, and the container ids are mostly arbitrary (objects in columnar mode are usually represented by integers). However, there are still columns that belong together, share an offset map, and have a common prefix to their names. These columns form a "virtual container" and the container id is used to identify that virtual container.

One important difference between xAOD types and container ids is that a container id is referring to a single container of a type. If you have e.g. two JetContainer instances in your tool, you need to use two different container ids for them. That is because in the columnar world the virtual containers come with completely separate columns, have separate offset maps, etc.

A given container id also only has a meaning within the context of one specific tool instance. If you have multiple instances of a tool they may be connected to different containers/columns each. If a tool has subtools they need to coordinate their container ids as well, making subtools a lot more tightly connected than in the xAOD world.

By default all referenced xAOD objects are const-qualified, as most tools will anyways work on const-qualified objects. In case your tool needs a non-const version of an object there is usually a "mutable" version of the container id available, which gives access to a mutable xAOD object and can be used wherever the corresponding const-qualified container id can be used, i.e. it doesn't introduce a separate container, but a different version of the same container.

Most classes in the columnar infrastructure are templates that take the container id as a template parameter. In part this is to use the correct type in xAOD mode, but it also serves an important role in columnar mode, as it allows to perform a lot of safety checks at compile time. E.g. it allows to guarantee that an ObjectId always refers to a valid entry in the container and that it can only be used with columns that are associated with that container.

For many of the containers there will be type aliases defined for some of the "common" infrastructure types, i.e. ObjectId, ObjectRange, OptObjectId, AccessorTemplate. This is meant to shorten the syntax for classes that users will regularly use in their own code. This is born out of experience during the prototyping stage when I found that the syntax that included all template parameters quickly became unwieldy.

The main motivation for representing container ids as "traits" structs is that it makes it possible to define parametric container ids. It also alleviates the need to have a single list of all container ids in a single place — each package can define its own container id structs as needed.

a template that provides a base definition of container id for a regular container

Essentially most container ids represent xAOD types underneath (in xAOD mode), and will as such share a lot of traits. Instead of repeating these over and over, I am instead defining them all here once, and then the individual definitions just need to derive from this and define a unique idName.

Definition at line 101 of file ContainerId.h.