RepositoryFactory

Constructs the right {@see RepositoryInterface} backend from one config array — the seam that makes the backend ONE CONFIG LINE. The array is the canonical nested `storage` block of a Milpa app's `config/app.php` (read in a plugin's `boot()` as `$config->get('storage', [...])`): `driver` picks the backend — `'file'`, `'sqlite'`, `'mysql'` or `'memory'` — and the remaining keys are that backend's constructor arguments (`path` for file and sqlite, `dsn` plus optional `user`/`password` for mysql, nothing for memory). Switching a store from a JSON file to SQLite or to a MySQL server is editing `driver` and its location key: no code changes anywhere. The factory adds ZERO semantics: each arm delegates to the backend's own constructor, so everything those constructors promise — lazy connections, lock disciplines, table derivation — holds unchanged for a factory-built repository. What it adds is teaching at the config seam: a missing or unknown driver names the four valid values, and a driver-specific key that is absent names the exact key with a copy-pasteable example, instead of failing somewhere deeper with a bare type error.

public static function fromConfig(array $storage, string $entityClass): Milpa\Data\RepositoryInterface

The repository the `storage` config describes, bound to `$entityClass`. Config shape: `['driver' => 'file'|'sqlite'|'mysql'|'memory']` plus the driver's own keys — `path` (file: the JSON collection file; sqlite: the database file), or `dsn` with optional `user` and `password` (mysql). Every misconfiguration throws an `\InvalidArgumentException` that teaches the fix: the four valid drivers, or the exact missing key with an example.

Parameters

Throws

\InvalidArgumentException when the driver is missing or unknown, or a driver-specific required key is absent