Cache Lifecycle and Performance

Cache Lifecycle and Performance

Lifecycle

1. A fixture is declared in test context.
2. FixtureKit generates cache by evaluating fixture definition in adapter isolation.
3. Each registered coder wraps the definition block and records what it observes — by default FixtureKit::ActiveRecordCoder records touched models and stores SQL restore statements + exposed ids.
4. Each test mounts cache data and rehydrates exposed records through Repository.

Mount Steps

For each coder's data, mount runs in this order:

1. Group models by connection_pool. For each pool, check out a connection via pool.with_connection.
2. Replay the coder's restore statements with referential integrity disabled (DELETEs + INSERTs in one batched call per connection).
3. If ActiveRecord.verify_foreign_keys_for_fixtures is true, validate foreign keys after the batch. A violation raises FixtureKit::Error with a stale-cache hint.
4. Reset primary key sequences for the touched tables. Uses the batched reset_column_sequences! on Rails 8.2+ or per-table reset_pk_sequence! on older versions. No-op on adapters whose PK generators advance from explicit-id INSERTs (MySQL, SQLite).

Cache Clearing

At runner start, FixtureKit clears cache_path by default.

• RSpec start point: before(:suite)
• Minitest start point: class run_suite before first generation

Preserve Cache

Set FIXTURE_KIT_PRESERVE_CACHE to keep cache files between runs:

FIXTURE_KIT_PRESERVE_CACHE=1 bundle exec rspec

Truthy values are case-insensitive: 1, true, yes.

Performance Notes

• Cache generation does real app writes once per fixture context.
• Cache mounting replays SQL in batches per connection with referential integrity disabled during replay.
• Repository reads are lazy and memoized per exposed name.