- Home
- Skills
- Makfly
- Superpowers Symfony
- Doctrine Fixtures Foundry
doctrine-fixtures-foundry_skill
- Shell
69
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill makfly/superpowers-symfony --skill doctrine-fixtures-foundry- reference.md7.6 KB
- SKILL.md1.1 KB
Overview
This skill helps evolve Symfony Doctrine models and database schema safely, focusing on integrity, performance, and controlled rollout. It guides Doctrine fixtures and Foundry tasks to design relations, tune queries, and verify lifecycle behavior. The goal is reliable migrations and predictable runtime behavior.
How this skill works
It inspects entity ownership and cardinality, identifies risky mapping changes, and recommends migration strategies that avoid destructive jumps. It highlights hot-path fetch/query patterns to eliminate N+1s and over-fetching, and proposes targeted tests to validate lifecycle callbacks and transactional boundaries. The skill outputs concrete entity/migration changes, performance decisions, and rollback notes.
When to use it
- Designing or changing entity relations and ownership semantics
- Planning schema evolution or database migrations for production
- Improving Doctrine query performance and eliminating N+1s
- Creating or refining doctrine fixtures and Foundry factories for tests
- Validating lifecycle callbacks, transactional boundaries, and integrity constraints
Best practices
- Keep owning and inverse sides coherent; model a single source of truth for relations
- Apply migration safety: break large destructive changes into smaller, reversible steps
- Tune fetch strategies only for identified hot paths; measure before optimizing
- Write targeted tests that exercise lifecycle events and transactional boundaries
- Avoid over-fetching by projecting required fields and using joins/partial objects
Example use cases
- Convert a ManyToMany with payload into an explicit join entity with clear ownership and migration plan
- Refactor eager fetches causing high memory use into optimized queries with pagination and explicit joins
- Add a new non-nullable column: implement backfill migration, deploy code to write defaults, then make column non-nullable
- Detect and fix accidental N+1s introduced by a new relation used in API endpoints
- Create Foundry factories and fixtures that mirror production constraints for reliable integration tests
FAQ
Split large changes into multiple releases: add new nullable columns or tables first, backfill data, switch code to use new structures, then remove old fields in a later release.
When should I change fetch strategy to avoid N+1s?
Change fetch strategies only after profiling and identifying hot paths. Prefer targeted query fixes (joins, eager-loading per query) over global mapping changes to reduce unintended side effects.