Core Structure Settings

When a table is created, each record in the data source becomes a row in the table.

The schema.columns section defines how each field of a record is modeled as a table column.

For example:

const table = dataManager.addTable("employees", {
    data: [
        { id: 1, name: "Alice", birthday: "2000-01-01" },
        { id: 2, name: "Bob", birthday: "2001-05-12" }
    ],
    schema: {
        columns: {
            id: { dataType: "number", isPrimaryKey: true },
            name: { dataType: "string" },
            birthday: { dataType: "date" }
        }
    }
});

In this example:

• Each object in data is a record.

• Each property of the record (id, name, birthday) becomes a column.

• The columns configuration defines how those fields are interpreted and managed by DataManager.

Core structure settings define:

• How a column maps to raw data

• How its value is resolved

• How its type is interpreted

• Whether it uniquely identifies a record

They form the structural foundation of column modeling.

Column Name

Each entry in schema.columns represents a column definition.

schema: {
    columns: {
        id: { dataType: "number" },
        name: { dataType: "string" }
    }
}

The object key (id, name) is the column’s logical identifier within the table.

This name is used when:

• Referencing fields in formulas

• Defining relationships

• Accessing row data

• Building views

If the name property is specified inside the column definition, it overrides the object key as the internal column name.

In most cases, the object key is sufficient.

dataName

dataName maps a column to a different field name in the raw data.

schema: {
    columns: {
        firstName: {
            dataName: "salesperson"
        }
    }
}

In this example:

• salesperson is the field in the original data

• firstName becomes the column name inside the table

This is useful when:

• Backend field names do not match frontend naming conventions

• Multiple fields need to be renamed for clarity

• The same data source is reused with different logical models

dataName does not modify the original data.

It only defines how the field is mapped during parsing.

value

The value property defines how the column value is resolved.

It can be:

• A field name

• A formula expression

Field Mapping

columns: {
    name: {
        value: "username",
    }
}

This explicitly maps the column to a specific field in the record.

If value is not defined, the column name is used as the field name by default.

Formula Column

If value contains a formula expression and dataType is set to "formula", the column becomes a computed column.

TotalUnits: {
    dataType: "formula",
    value: "=[@UnitsInStock] + [@UnitsOnOrder]"
}

In this case:

• The column does not directly map to a raw data field

• Its value is computed from other fields in the same record

Formula columns behave like regular data columns after evaluation.

dataType

dataType defines how the column value is interpreted.

Common types include:

• "string"

• "number"

• "boolean"

• "date"

• "formula"

• "object"

• "array"

The data type affects:

• Value parsing (especially for dates and numbers)

• Formula behavior

• Validation logic

• Integration with views

For example, when JSON data contains date strings:

columns: {
    birthday: {
        dataType: "date"
    }
}

The value is converted into a date value during parsing.

If dataType is not specified, the type is inferred from the value.

isPrimaryKey

isPrimaryKey marks a column as part of the table’s primary key.

columns: {
    id: {
        isPrimaryKey: true
    }
}

A primary key:

• Uniquely identifies each record

• Is required for relationships

• Is required for certain advanced features such as cross views

Primary key constraints are enforced at the table level.

If multiple columns are marked as isPrimaryKey, they form a composite key.

Structural Responsibility

Core structure settings define:

• How a column maps to raw data

• How its value is computed

• How its type is interpreted

• Whether it uniquely identifies records

They do not control:

• Validation rules

• Display formatting

• Filtering behavior

• Styling

Those capabilities are configured separately in other column modeling sections.