playbooks

home / skills / makfly / superpowers-symfony / doctrine-fixtures-foundry

doctrine-fixtures-foundry skill

/skills/doctrine-fixtures-foundry

This skill helps evolve Symfony Doctrine models and fixtures safely, ensuring integrity, performance, and rollout discipline across migrations and tests.

npx playbooks add skill makfly/superpowers-symfony --skill doctrine-fixtures-foundry

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
1.1 KB
---

name: symfony:doctrine-fixtures-foundry
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Evolve Symfony Doctrine models and schema safely with integrity, performance, and rollout discipline. Use for doctrine fixtures foundry tasks.
---

# Doctrine Fixtures Foundry (Symfony)

## Use when
- Designing entity relations or schema evolution.
- Improving Doctrine correctness/performance.

## Default workflow
1. Model ownership/cardinality and transactional boundaries.
2. Apply mapping/schema changes with migration safety.
2. Tune fetch/query behavior for hot paths.
2. Verify lifecycle behavior with targeted tests.

## Guardrails
- Keep owning/inverse sides coherent.
- Avoid destructive migration jumps in one release.
- Eliminate accidental N+1 and over-fetching.

## Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.

## Output contract
- Entity/migration changes.
- Integrity and performance decisions.
- Validation outcomes and rollback notes.

## References
- `reference.md`
- `docs/complexity-tiers.md`

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

How do I avoid destructive migration jumps?

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.