Problem
Many Postgres apps have materialized views on top of the tables StagingTable writes to. After a transfer, the matview is stale until someone runs REFRESH MATERIALIZED VIEW. Users currently do this manually in an after_transfer callback.
Proposal
StagingTable.stage(User,
after_transfer: StagingTable::Helpers.refresh_matview(:user_stats, concurrently: true)
) { |s| s.insert(rows) }
- Works with
CONCURRENTLY (requires a unique index on the matview — document)
- Multiple matviews: pass an array
Acceptance criteria
- Postgres-only helper; clear error on other adapters
- Supports
concurrently: true/false
- Docs reference the matview unique-index prerequisite
Problem
Many Postgres apps have materialized views on top of the tables StagingTable writes to. After a transfer, the matview is stale until someone runs
REFRESH MATERIALIZED VIEW. Users currently do this manually in anafter_transfercallback.Proposal
CONCURRENTLY(requires a unique index on the matview — document)Acceptance criteria
concurrently: true/false