# Create Doctrine Repository

> Create the repository in the Adapter layer. This is the ONLY class that touches the database — all handlers delegate to it. Covers multistore patterns with ShopConstraint when the entity requires it. Trigger: "create repository for {Domain}".

- Skill: `prestashop/create-doctrine-repository` (Agent Skill)
- Install (CLI): `npx skillmds@latest add prestashop/create-doctrine-repository`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prestashop/create-doctrine-repository/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: prestashop (https://skillmd.com/u/prestashop)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prestashop/create-doctrine-repository

---


# create-doctrine-repository

See [CQRS/CONTEXT.md](../../CONTEXT.md#repository) for conventions (stateless, no Context dependency, multistore tier model, typed exceptions).

## 1. Choose the base class

Create `src/Adapter/{Domain}/{Domain}Repository.php`. Choose the base class based on the multistore tier table in CONTEXT.md.

## 2. Core methods

Implement these methods (adapt naming to your domain):

- `get{Domain}({Domain}Id $id): {LegacyObjectModel}` — loads the ObjectModel, throws `{Domain}NotFoundException` if not found
- `create(...): {Domain}Id` — calls ObjectModel `save()` or `add()`, wraps in try/catch, returns new ID
- `update(...)` — calls ObjectModel `save()` or `update()`
- `delete({Domain}Id $id)` — deletes the entity, respects multistore if applicable

**Reference:** `src/Adapter/Tax/CommandHandler/` uses a simple repository pattern, `src/Adapter/Carrier/CommandHandler/` uses `AbstractMultiShopObjectModelRepository`

## 3. Multistore pattern (when using AbstractMultiShopObjectModelRepository)

- Receive `ShopConstraint` as a method parameter — never read it from Context
- Call `$shopIds = $this->getShopIdsByConstraint($shopConstraint)` at the start of every write
- Iterate `$shopIds` and apply the write for each shop context
- Modes: `ShopConstraint::allShops()`, `ShopConstraint::shop($shopId)`, `ShopConstraint::shopGroup($groupId)`
- Single-shop installs still go through this path (returns array with one ID)

## 4. Sub-resource methods (if applicable)

For entities with has-many sub-resources, two strategies:

### Atomic replace (simpler)
- `set{SubResource}s({Domain}Id, array $items)` — delete all existing rows, insert new set
- Wrap in transaction — partial replace corrupts data

### Incremental update (cleaner)
- Compare existing rows with new collection, apply only changes
- Preferred when sub-resources have their own identity

## Rules

Conventions (stateless, no Context, typed exceptions) are in [CQRS/CONTEXT.md](../../CONTEXT.md#repository). Skill-specific reminders:

- Never use `Db::getInstance()` — use Doctrine DBAL or ObjectModel methods
- Never hard-code `Context::getContext()->shop->id` — receive shop as parameter
- The repository **only persists** — no business validation (uniqueness, required-by-config, related-record existence). That belongs in the `{Domain}Validator` service the handler calls (see [CQRS/CONTEXT.md](../../CONTEXT.md) → Handlers → Validation placement). The only checks here are existence guards via the base helper `assertObjectModelExists` (add a dedicated `assert{Related}Exists` rather than fetching-and-discarding)