For ops migrating from one journal backend to another (SQLite → Cassandra, InMemory → SQLite during prod-deploy, etc), there's no built-in tool today. Each pid has to be migrated individually via custom scripts.
Scope:
- Generic helper `migrateJournal(source, target, opts?)`:
- Iterates pids on `source.persistenceIds()`.
- For each pid: reads all events, appends to target with the same sequence numbers + tags + timestamps.
- `opts.parallelism`, `opts.dryRun`, `opts.persistenceIdFilter`.
- Returns a per-pid summary (`{ pid, eventCount, status: 'ok' | 'skipped' | 'failed' }`).
Tests:
- InMemory → InMemory round-trip preserves seq + content.
- Source has 100 pids, target gets them all.
- Failure on one pid doesn't abort the whole migration (`onError: 'continue' | 'abort'`).
Out of scope:
- Snapshot store migration — same shape but separate API.
- Live migration with concurrent writes — much harder; this is for offline / scheduled-window ops.
Estimate: 2-3 days.
Related: #9 (one-shot migration script for envelope wrapping) — different operation; this is bytes-level, that one is shape-level.
For ops migrating from one journal backend to another (SQLite → Cassandra, InMemory → SQLite during prod-deploy, etc), there's no built-in tool today. Each pid has to be migrated individually via custom scripts.
Scope:
Tests:
Out of scope:
Estimate: 2-3 days.
Related: #9 (one-shot migration script for envelope wrapping) — different operation; this is bytes-level, that one is shape-level.