drupflare/worker - v1.0.0
    Preparing search index...

    Interface DumpCursor

    Where a resumable export has got to.

    Plain JSON with no functions and no handles, because it travels back to the client between invocations. The table is named rather than indexed: an index into a list rebuilt from sqlite_master shifts the moment a table is created or dropped mid-export, so a resume would enter the wrong table and produce a dump that restores cleanly and is wrong.

    interface DumpCursor {
        afterRowid?: number | null;
        emitted?: number;
        offset?: number | null;
        phase: "done" | "rows" | "ddl" | "later";
        shape?: string;
        table?: string | null;
    }
    Index
    afterRowid? emitted? offset? phase shape? table?
    afterRowid?: number | null

    Keyset position: the last rowid emitted for DumpCursor.table.

    NULL means "nothing emitted from this table yet", and it is not the same as 0. A rowid is signed, so 0 is an ordinary position a row can occupy -- Drupal's anonymous user is users rowid 0 -- and using it as the start sentinel dropped that row from every dump.

    emitted?: number

    rows emitted from this table so far, so limitPerTable survives a resume

    offset?: number | null

    OFFSET position, used only for a WITHOUT ROWID table

    phase: "done" | "rows" | "ddl" | "later"
    shape?: string

    Fingerprint of the dump SHAPE this cursor belongs to.

    The cursor describes POSITION; the options describe shape, and they arrive separately on every call because the HTTP surface rebuilds them from query parameters. Resuming an ?all=1 export with the default options would splice two different dumps into one that looks whole. Checked rather than trusted -- dumpChunk throws instead of splicing.

    table?: string | null

    the table being emitted, by name

    Settings
    Member Visibility

    On This Page
    Properties