seed:run keeps a per-seed run cache so a seed whose code is unchanged since its last successful run — for the same environment — is skipped without touching the database. Unlike migrations, seeds have no database table recording what has run, so this cache is the only record that a seed already ran. When every selected seed is already cached, the runner reports each as up to date (cached) and returns without re-seeding.
What the cache stores
One JSON file per seed lives undervar/cache/seeds/ at the project root, so editing a single seed invalidates only that seed’s entry. Each entry records the cache version, the seed name, a fingerprint hash, and the time it ran. Only successful runs are written, and the directory is safe to delete at any time.
How an entry is fingerprinted
The hash covers the seed’s class name, the source of itsrun method, and the active environment (APP_ENV). Any change to the seed’s code — or running against a different environment — yields a new hash and therefore a cache miss, so the seed runs again.
When the cache is bypassed
| Trigger | Effect |
|---|---|
--drop | Seeded data is cleared, so a cache hit would wrongly skip re-seeding; the cache is bypassed and every selected seed re-runs. |
--no-cache | Explicit escape hatch — reads and writes are skipped for the run. |
--drop and --no-cache exist for exactly that case.
Next steps
- Running seeds: run seeds, with or without the cache.
- Overview: why seeds rely on the cache instead of a tracking table.