mcpField
D
doctrine-transactions

doctrine-transactions

github.com/dev-toolingsData & databases22798 installsUpdated 3w ago
Repository

About doctrine-transactions

doctrine-transactions is a skill for handling Symfony Doctrine ORM transactions. It guides transaction boundaries, locking choices, and rollback recovery, with emphasis on one flush per operation and short-lived transactions.

Key features

  1. 01Set transaction boundaries in services
  2. 02Use wrapInTransaction()
  3. 03Choose optimistic or pessimistic locking
  4. 04Handle lock conflicts and constraint errors
  5. 05Clear and refetch entities after rollback

Use cases

  1. 01Commit related writes as one transaction
  2. 02Prevent concurrent edits from overwriting data
  3. 03Recover from failed flushes or lost connections

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dev-toolings/superpowers-symfony --skill doctrine-transactions

After installing, type/doctrine-transactionsin Claude Code to confirm it loaded.

Bundled filesreference.md

Details

From the project README

Doctrine Transactions (Symfony)

Use when

  • Several writes must succeed or fail together.
  • Two users or workers can edit the same row concurrently.
  • Deciding where to flush and who owns the transaction boundary.
  • Recovering after a failed flush, a constraint violation, or a lost connection.

Default workflow

  1. Place the transaction boundary in the service layer, not in the controller.
  2. Group related changes and flush once, inside wrapInTransaction().
  3. Pick the concurrency strategy: #[ORM\Version] optimistic locking for edits, PESSIMISTIC_WRITE for short critical sections.
  4. Handle OptimisticLockException and constraint violations explicitly.
  5. After a rollback, clear the EntityManager and re-fetch what you still need.

Guardrails

  • On ORM 3, EntityManager::transactional() is gone: use wrapInTransaction().
  • Outside an explicit transaction each flush commits on its own, so avoid several flushes per operation.
  • Keep transactions and pessimistic locks short; no HTTP calls or mail inside.
  • Do not reuse entities from a failed unit of work.

Progressive disclosure

  • Use this file for execution posture and risk controls.
  • Open references when deep implementation details are needed.

Output contract

  • Transaction boundaries with a single flush per operation.
  • The locking strategy chosen per entity, and how conflicts reach the user.
  • Rollback handling and the state of the EntityManager after it.

References

  • reference.md

Comments

Markdown supported