Problem
The biggest footgun in the current API: if a user naively splits a staging workflow across multiple ActiveJob/Sidekiq jobs, each job checks out a different DB connection, and the temp staging table disappears between jobs. The README mentions the limitation but offers no fix beyond "stay on the same connection."
Proposal
A helper that auto-swaps to persistent staging (see the non-temp issue) when running inside an ActiveJob context:
class ImportUsersJob < ApplicationJob
include StagingTable::JobHelper
def perform(batch_id)
staged_table(User, key: batch_id, temporary: false) do |staging|
staging.insert(batch_for(batch_id))
end
end
end
class TransferUsersJob < ApplicationJob
include StagingTable::JobHelper
def perform(batch_id)
staged_table(User, key: batch_id, temporary: false, create: false) do |staging|
staging.transfer
end
end
end
key: keeps the same persistent staging table across jobs
- The wrapper ensures
drop_table happens exactly once (at the last job), or on failure/timeout
- Optional sweeper job for stranded tables older than TTL
Acceptance criteria
- Works with ActiveJob; Sidekiq-specific integration optional
- Stranded tables cleaned up by a configurable sweeper
- Docs: full worked example with job chain + failure handling
Problem
The biggest footgun in the current API: if a user naively splits a staging workflow across multiple ActiveJob/Sidekiq jobs, each job checks out a different DB connection, and the temp staging table disappears between jobs. The README mentions the limitation but offers no fix beyond "stay on the same connection."
Proposal
A helper that auto-swaps to persistent staging (see the non-temp issue) when running inside an ActiveJob context:
key:keeps the same persistent staging table across jobsdrop_tablehappens exactly once (at the last job), or on failure/timeoutAcceptance criteria