Window Definition

The window property of a table schema defines reusable window specifications for use in WINDOW() formulas.

Window definitions:

• Belong to the table schema

• Do not modify stored data

• Do not affect remote operations

• Do not change column structure

• Serve as named window configurations for formula evaluation

They provide a shorthand mechanism that allows window specifications to be defined once and reused across multiple calculations.

Why Define Windows in Schema

When using WINDOW() formulas, expressions often repeat:

• PARTITIONBY

• ORDERBY

• Frame definitions (FRAMEROWS, FRAMERANGE, FRAMEGROUPS)

Instead of duplicating these expressions in every formula, you can define a named window in the schema and reference it by name.

This improves:

• Readability

• Maintainability

• Consistency across calculations

Basic Structure

The window property is defined as a key–value collection.

interface ISchemaOption {
    window?: {
        [name: string]: string;
    };
}

Each key is the window name.

Each value is a WINDOWDEF formula expression.

Defining a Base Window

Example:

dataManager.addTable("orders", {
    schema: {
        window: {
            YearPartition:
                '=WINDOWDEF(PARTITIONBY([Product], YEAR([@OrderDate])))',
            RunningFrame:
                '=WINDOWDEF(PARTITIONBY([Product]), ORDERBY([@OrderDate]), FRAMEROWS(-1, [@]))'
        }
    }
});

Each definition specifies:

• Partition logic

• Optional ordering logic

• Optional frame logic

The definition itself does not perform aggregation.

It only defines the window context.

Using a Named Window

A named window can be referenced inside a WINDOW() formula:

=WINDOW(SUM([Sales]), "YearPartition")

The named window supplies:

• PARTITIONBY

• ORDERBY

• Frame configuration

The aggregation function (for example, SUM) is still specified in the WINDOW() call.

Window Chaining

Window chaining allows a previously defined window to be reused and partially overridden.

When a named window is referenced together with additional window clauses:

• Expressions provided in the WINDOW() call override the corresponding parts of the base window.

• Unspecified parts are inherited.

Examples:

// Reuse base window entirely
WINDOW(SUM([Sales]), "YearPartition")

// Override ORDERBY
WINDOW(SUM([Sales]), "YearPartition",
       ORDERBY([@OrderDate]))

// Override frame only
WINDOW(SUM([Sales]), "YearPartition",
       FRAMEROWS([@-2], [@]))

Override rules:

• PARTITIONBY, ORDERBY, and frame expressions defined in the call replace those in the base window.

• Any part not explicitly provided remains unchanged.

This allows flexible reuse while keeping window definitions centralized.

Frame Types and Exclude Modes

Window definitions may include frame expressions such as:

• FRAMEROWS

• FRAMERANGE

• FRAMEGROUPS

Frame expressions may optionally include exclude modes.

These syntaxes are part of the window function language and are evaluated during formula calculation.

Data Manager provides the foundational support for window functions. For detailed usage and configuration within TableSheet, see the TableSheet Window Functions documentation. This page focuses on schema-level window configuration only.

Responsibility Boundary

Window definitions:

• Extend the schema with reusable window specifications

• Affect only formula evaluation

• Do not alter stored records

• Do not participate in data synchronization

• Do not introduce relationships between tables

They serve as a formula infrastructure mechanism within the DataManager schema.

This maintains a clear separation between:

• Data structure (columns and relationships)

• Formula semantics (window behavior)

• View rendering