prorm API Reference
    Preparing search index...

    Interface TableOptions

    Table-level options for CREATE TABLE — the engine, charset, comment, partitioning and any indexes or constraints declared inline.

    interface TableOptions {
        ifNotExists?: boolean;
        engine?: string;
        charset?: string;
        collate?: string;
        comment?: string;
        initialAutoIncrement?: number;
        rowFormat?: string;
        indexes?: TableIndex[];
        constraints?: TableConstraint[];
        uniqueKeys?:
            | Record<string, string[]>
            | { name?: string; fields: string[] }[];
        tablespace?: string;
        inherit?: string;
        partitionBy?: string;
        systemVersioning?:
            | boolean
            | {
                historyTable?: string;
                validFromColumn?: string;
                validToColumn?: string;
            };
    }
    Index
    ifNotExists?: boolean
    engine?: string
    charset?: string
    collate?: string
    comment?: string
    initialAutoIncrement?: number
    rowFormat?: string

    Row format for MySQL/MariaDB (e.g., 'DYNAMIC', 'FIXED', 'COMPRESSED')

    indexes?: TableIndex[]
    constraints?: TableConstraint[]
    uniqueKeys?: Record<string, string[]> | { name?: string; fields: string[] }[]

    Unique keys to create with the table.

    Both shapes are accepted because both have always been passed: the legacy { name: fields[] } map, and the UniqueKeyOptions-style array that ModelOptions.uniqueKeys is declared as. The dialects already branch on Array.isArray; the type now says so.

    tablespace?: string

    PostgreSQL tablespace

    inherit?: string

    PostgreSQL: inherit from parent table

    partitionBy?: string

    PostgreSQL: partition by clause

    systemVersioning?:
        | boolean
        | {
            historyTable?: string;
            validFromColumn?: string;
            validToColumn?: string;
        }

    System-versioned (temporal/bitemporal history) table support, e.g. MariaDB/SQL Server SYSTEM_VERSIONING = ON (plain boolean) or SAP HANA PERIOD FOR SYSTEM_TIME (...) WITH SYSTEM VERSIONING, which also accepts a config object naming the history table and period columns. Dialects that don't support system-versioned tables should ignore this option.

    Type Declaration

    • boolean
    • { historyTable?: string; validFromColumn?: string; validToColumn?: string }
      • OptionalhistoryTable?: string

        Name of the history table that stores prior row versions. When omitted, the dialect's default/implicit history table naming applies (e.g. HANA auto-generates one when no HISTORY TABLE clause is given).

      • OptionalvalidFromColumn?: string

        Name of the "row start"/valid-from period column. Defaults to valid_from when omitted.

      • OptionalvalidToColumn?: string

        Name of the "row end"/valid-to period column. Defaults to valid_to when omitted.