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

    Function countingSql

    • Wraps ctx.storage.sql so the HOST's own writes land in the tally too.

      A correction rather than an addition. execSql() is the only path tallyWrite() was ever called from, and execSql() is the PHP driver's entry point -- so the tally, and this.rowsWritten with it, could only ever see Drupal's statements. Every write the host makes on its own behalf goes through this.sql.exec() directly and was invisible: the cfw_page insert, the cfw_fill_queue delete, cfw_meta, the serve-table DDL.

      That is not a rounding error. The cfw_page insert carries the whole rendered page -- 12,304 bytes for the front page -- and cfw_page is indexed, so it is the single largest write in a fill. A fill measured at "12 rows" through the old instrument reported 0 for the statement that stores the product of the fill.

      Rows written is the meter that binds the regeneration ceiling, so an instrument that cannot see the host's half cannot price the fill lane at all. Read-only statements pass through untouched and are not counted: rowsWritten on a cursor mid-iteration is not a settled number, and a write statement returns no rows, so reading it immediately is only safe for the write case.

      Type Parameters

      Parameters

      • sql: T
      • getTally: () => WriteTally | undefined
      • OptionalonWrite: (rows: number) => void

      Returns T