{'fraction_non_alphanumeric': 0.014858841010401188, 'fraction_numerical': 0.0014858841010401188, 'mean_word_length': 4.946987951807229, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 5, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
High Level Interface to Conditions Data at Belle II

The Belle II experiment at the SuperKEKB e+e− accelerator is preparing for taking first collision data next year. For the success of the experiment it is essential to have information about varying conditions available in the simulation, reconstruction, and analysis code. The interface to the conditions data in the client code was designed to make the life for developers as easy as possible. Two classes, one for single objects and one for arrays of objects, provide a type-safe access. Their interface resembles that of the classes for the access to event- level data with which the developers are already familiar. Changes of the referred conditions objects are usually transparent to the client code, but they can be checked for and functions or methods can be registered that are called back whenever a conditions data object is updated. The framework behind the interface fetches objects from the back-end database only when needed and caches them while they are valid. It can transparently handle validity ranges that are shorter than the finest granularity for the validity of payloads in the database. Besides an access to the central database the framework supports local conditions data storage which can be used as fallback solution or to overwrite values in the central database with custom ones.


Introduction
The Belle II detector [1] and the SuperKEKB accelerator are currently under construction at the KEK laboratory in Tsukuba, Japan. The aim of this next generation B factory experiment is to collect 50 times more data than its predecessor Belle [2] and to use this data to search for new physics in a variety of B meson, charm hadron, or τ lepton decays with unprecedented precision. This requires detailed information on varying calibration and detector conditions to be available when analyzing the data.

Software Framework
The Belle II software Framework (basf2) [3] is a C++/Python framework to process the events recorded by the Belle II detector. Events are grouped in so-called runs which mark a datataking period with stable operating conditions. Recorded events are processed one by one using a sequential set of algorithms called "modules." As all events are independent from each other we can benefit from current architectures with multiple cores by processing different events in parallel. To share the large amounts of static memory and simplify the implementation of the single modules we parallelize using the fork system call which enables copy-on-write sharing of memory pages between processes. The Belle II Conditions Database is designed as a representational state transfer (REST) service. Communication is performed by standard HTTP using XML and JSON data. The database manages conditions data on run granularity. Binary objects called payloads which are defined for a certain interval of validity (IoV) are grouped into so-called global tags. The conditions database is by design agnostic to the contents of the payloads and only identifies them by name and revision number. The integrity of all payloads is verified using a checksum of the full content.
The choice of a standardized REST api makes the client implementation independent of the actual database implementation details and allows for a simple and flexible implementation of clients in different programming languages.
One requirement for the conditions client interface is that it needs to also work inside the data acquisition network which does not have a network connection to the outside. To facilitate this the client can also use a local, file-based backend which reads the list of payloads from an index file and the payload contents from files in a given directory. Command line tools written in Python allow to easily download all payloads and IoVs defined in a global tag to be used locally or upload a locally prepared folder to be available for all users.

Access of Conditions Objects
The software framework assumes that payload contents are serialized ROOT [4] objects. User access to conditions objects is provided using two interface classes, one for single objects called DBObjPtr and one class for arrays of objects called DBArray. These class references payload objects, so called DBEntry objects in a global store, the DBStore. Multiple instances of the interface class all point to the same object. Access to the conditions objects is available in C++ and in Python where the class interface has been designed to be as close as possible to the already existing interface for event level data. Users familiar with the event level storage should have little problems accessing conditions data.
The interface classes always point to correct payload object for the current run, updates are transparent to the user. If the user needs to be aware when the object changes he can either manually check for changes or register a callback function to be notified on change. Figure 1 visualizes the relations between all the entities. granularity: Payload objects which inherit from an abstract base class IntraRunDependency can contain multiple objects for different parts of the run. The correct one will be selected transparently depending on certain criteria like event number or timestamp.

Creation of Condition Data
To create payload objects we also provide two interface classes to simplify the procedure of preparing the objects, serializing them and committing them to the database. Users can just instantiate one of the creation classes, add objects to them and commit them to the configured database with a user supplied IoV. This includes support for intra run dependency. The possibility for a local file based database allows for easy preparation and validation of payloads as is needed during the calibration of the detector. Once all payloads are aggregated locally they can be easily tested and then uploaded to the central database using a simple command line tool.

Storage backends
Payloads in the central database are represented by logical filename, revision number and content checksum. While the central server provides a way to download all payloads directly via HTTP this is not the only possible distribution system. As the payloads are usually a large number of small files it might be beneficial to investigate alternative ways to distribute them. The database client can easily accommodate different storage implementations for the payloads by defining a cascade of storage backends to look for the actual payload content. After downloading the metadata on all needed payloads it will check all configured backends one by one for the needed files. If no storage backend contains the required payload it will automatically try to directly download the payload from the central server.
Currently only file based storage, for example shared filesystems or Cern-VM FS [5] are implemented. However it would be trivial to extend this to other technologies, for example keyvalue based storage systems like MICA [6]. Also hybrid systems where multiple payload objects are consolidated into larger archives similar to git packfiles [7] could be considered as well. This allows for a highly flexible distribution of the needed payload files which can be adapted as the content of the conditions database evolves.
The fallback solution to simply download missing payloads over http makes it trivial to use