CHAP 0.3.2: a store that writes each call once

The protocol packages move together to 0.3.2. Each call now writes what it
changed to the store, so a long run no longer slows as its log grows.
chap-analytics 0.2.3, on its own track, reads the new store.

npm install @brightbeamai/chap-coordinator@0.3.2
pip install "chap-coordinator==0.3.2"

Fixed

• Writes that slowed as the log grew. SqliteStore, in both
  coordinators, wrote the whole workspace, its log included, as one JSON
  document after every call, so a long run slowed with the square of its
  length. Each call now writes its own audit entries, the objects it changed
  and the workspace's own fields, in one transaction, so the cost of a call
  no longer grows with the log.
• Objects shared with the caller. A call's handler works on its own copy
  of the call's params, and the caller receives a copy of the result. Before,
  a reviewer list passed to two review.request calls in TypeScript was
  shared by both tasks, so widening one review widened the other.
• SqliteStore from CommonJS. Loaded with require, it reported
  better-sqlite3 missing when it was installed.

Changed

• The tables in a SQLite file. chap_meta, chap_entries (one row per
  audit entry) and chap_objects (one row per object). A file an earlier
  release wrote is moved into them when it is first opened, and the old table
  is kept, unchanged, as chap_workspaces_v1. A view named chap_workspaces
  takes its place, so a script that read the old table reads the current
  state. An earlier release then refuses to open the file, with the error
  "views may not be indexed"; keep a copy of a database you may take back to
  0.3.1.
• A second writer is refused. Each write names the number of audit
  entries the coordinator expects the store to hold. SqliteStore and
  MemoryStore refuse a write that does not match with a
  StoreConflictError and write nothing, so a second coordinator on the same
  workspace is reported and the entries already stored are kept.
  SPECIFICATION.md section 10.3.
• A failed write is reported. With no onStoreError (TypeScript) or
  on_store_error (Python, new), it is printed to stderr or logged on the
  chap_coordinator logger, and the next write carries what it missed.
• Store.apply. A store may implement apply(change) to receive what a
  call changed. A store with only save works as before, at the old cost.

chap-analytics 0.2.3

• The 0.3.2 store. from_sqlite reads the new tables, in one read
  transaction, and a file from an earlier release as before.

The full entry is in the
changelog.