Setu-TS
    Preparing search index...

    Interface CosmosEntityMapping

    How one entity name maps onto a physical Cosmos container.

    0.2.0

    interface CosmosEntityMapping {
        container?: string;
        partitionKey?: string | readonly string[] | readonly (readonly string[])[];
        primaryKey?: string;
    }
    Index
    container? partitionKey? primaryKey?
    container?: string

    The container name. Defaults to the entity name itself, so getRepository('orders') needs no mapping at all.

    partitionKey?: string | readonly string[] | readonly (readonly string[])[]

    The document field path(s) carrying the partition key.

    Absent, the adapter discovers it from the container definition, which is both cheaper for the developer and safer: a wrong partition key is a silent 404 rather than an error. When present it is VALIDATED against the container definition, so a mistyped path is refused by name at first use.

    A nested path is written as an array (['address', 'city']); a hierarchical (MultiHash) partition key is written as an array of paths.

    primaryKey?: string

    The repository-visible primary-key field name. Defaults to 'id'.

    A Cosmos document's identity is always its id property, so a mapping that names another field renames it onto id on write and back on read — the MongoEntityMapping.primaryKey behaviour, for the same reason.

    Settings
    Member Visibility

    On This Page
    Properties