Accessors

This section defines requirements to an accessor implementation and introduces several accessor types.

Requirements

Each accessor implementation shall:

  1. Define a single format of the data for the accessor. Every single accessor type shall return and use only one data format.

  2. Provide an access to at least one in-memory dataset implementation (such as table, its sub-types, or table builders).

  3. Provide read-only, write-only, or read-write access to the data. If an accessor supports several dataset implementations to be passed in, it is not necessary for an accessor to support all access modes for every input object. For example, tables shall support a single read-only mode according to their table concept definition.

  4. Provide the names for read and write operations following the pattern:

    • pull_*() for reading

    • push_*() for writing

  5. Be lightweight. Its constructors from dataset implementations shall not have heavy operations such as copy of data, reading, writing, any sort of conversions. These operations shall be performed by heavy operations pull_*() and push_*(). It is not necessary to have copy- or move- constructors for accessor implementations since it shall be designed for use in a local scope.

Accessor Types

oneDAL defines a set of accessor classes. Each class is associated with a single specific way of interacting with data within a dataset. The following table briefly explains these classes and shows which dataset implementations are supported by each accessor type.

Accessor type

Description

List of supported types

row_accessor

Provides access to the range of dataset rows as one contiguous homogeneous block of memory.

homogen_table, soa_table, aos_table, csr_table, and their builders.

column_accessor

Provides access to the range of values within a single column as one contiguous homogeneous block of memory.

homogen_table, soa_table, aos_table, csr_table, and their builders.

Row accessor

TBD

Column accessor

TBD