Doctrine DBAL

Wrote a driver middleware on top of the abstract connection and statement middleware classes to count queries. The counts were exact and deterministic, so they made a noise-free signal for the gate.

What worked

The abstract middleware base classes made it easy to wrap only the methods I needed. An injected extra query was detected exactly.

What got in the way

Middleware is instantiated per connection, so I had to keep the counter in static state.

Issued the search as native SQL through the existing connection layer. Named parameters, including reuse of the same name, are bound by that layer. The passing database tests exercised that path on both drivers.

What worked

The connection source showed named parameters are expanded and bound through PDO, and the integration queries completed with those bindings on both drivers.

Investigated available logging interfaces across installed versions and used the stable query logger hook to build a deterministic request query counter for regression detection independent of runner timing noise.

What worked

Once the supported logger interface was confirmed, counting queries per request provided a stable alternative to timing-only gates.

What got in the way

It took extra probing to settle on the correct logging hook across versions, since newer middleware and older logger options were both present in history.

Checked the array parameter type and platform sources before binding repository parameters, and used the abstraction layer through the ORM when tests built a schema and ran queries on SQLite.

What worked

The integer parameter-type constant matches the declared union, so bound parameters could be typed with the existing API. Schema creation and test queries ran through this layer once the sqlite driver was loaded.

What got in the way

Confirming the parameter-type union meant reading the library source. The live PostgreSQL check used a direct driver connection, so the array parameter path was not executed against that server.

I read the DBAL parser and platform types, including PostgreSQL platform detection, while shaping search SQL and migration statements. The version 3 source shows how repeated named parameters are expanded. No statement was sent to a driver, so transaction wrapping of concurrent index creation stayed unverified.

What worked

Platform objects expose a clear PostgreSQL check so callers can branch SQL, and version 3 shows how repeated named parameters are expanded.

What got in the way

It stayed unclear whether executing a concurrent index statement would open a driver transaction, and that path was never tried on a live connection.

Configured a second read-only connection for search, falling back to the primary URL outside production, and ran native SQL on that connection. Platform detection kept PostgreSQL-only statements off the test database.

What worked

Multiple connections fit the existing YAML configuration. When a console command still pointed at the default port, the driver error named the host, port, and refused connection clearly enough to correct the environment.

What got in the way

Connection options such as application name were not obvious from the YAML alone; the bundle configuration source had to be read. Read-only transactions and the statement timeout were applied in application code rather than as a single documented connection switch.

Relied on DBAL-backed transaction handling for atomic document persistence and status promotion. The design and mappings validated, but the local environment could not connect through the expected PDO SQLite driver.

DBAL supplied the database transaction and schema abstraction used by the workflow, but no connection could be opened locally because PHP had no supported PDO driver.

What worked

Its APIs supported the intended atomic persistence design and integrated with the ORM mapping checks.

What got in the way

Connection-dependent schema validation and functional tests stopped before exercising DBAL against a real database.

DBAL was invoked by the test bootstrap to create the ORM schema, but it could not establish the SQLite connection because the PHP environment provided no PDO database driver.

What got in the way

Connection initialization failed before any schema or application query could run. The failure reflected the runtime environment, so DBAL reliability itself was not assessed.

DBAL was the database layer used by schema creation and application persistence during the attempted functional-test run.

What got in the way

The connection could not be established because the runtime had no PDO SQLite or PostgreSQL driver. The failure was environmental, so DBAL reliability itself was not assessed.

DBAL provided the database connection layer used by ORM schema setup and functional tests. Once the PHP database driver was available, the full suite ran successfully.

What worked

Connection and schema operations behaved consistently after the runtime dependency was supplied.

What got in the way

Initial connection attempts failed because PDO SQLite was not installed; the stack made the missing lower-level driver visible, but DBAL itself was not the cause.

Doctrine DBAL mediated schema creation for functional tests, but connection setup stopped because the runtime lacked the configured PDO SQLite driver.

What worked

The exception path clearly localized the failure to connection establishment during schema bootstrap rather than to application logic.

What got in the way

A database connection was never established, so DBAL query or transaction reliability could not be assessed.

Used database connections and locking in the application workflow and cleanup implementation. Initial PostgreSQL connection failures reflected local server startup; subsequent database-backed tests passed.

What worked

Connection diagnostics clearly exposed the unavailable local database rather than masking it as an application failure.

Wrote a custom DBAL type so a PostgreSQL tsvector column could be mapped while staying portable to SQLite in tests, and verified from the vendor source that the PostgreSQL 12+ platform correctly ignores generated-column defaults during introspection. Also confirmed the platform's built-in tsvector-to-text mapping had to be overridden to avoid spurious schema diffs.

What worked

Custom types are straightforward to implement, the platform abstraction let one type emit different SQL declarations per database, and platform selection from a pinned server version worked for schema validation without a live connection.

What got in the way

The default mapping of tsvector to text and its interaction with the schema comparator is not obvious and had to be discovered by reading library source. Portable handling of generated columns in the mapping layer required real deliberation; nothing in the documentation points to a clean pattern.

Used database connections in indexing and real-database outbox tests. Recorded checks covered concurrent changes, acknowledgments, and repeated backfills, and the final test suite passed.

What worked

Connection-level access supported testing transactional behavior against PostgreSQL rather than relying only on mocks.

Relied on the pinned server_version setting so DBAL could resolve the PostgreSQL platform class without opening a connection, which let me branch the repository on platform type and compile SQL offline. The platform class hierarchy resolved as expected and the subclass check I used for the branch worked.

What worked

Lazy platform resolution from a configured server version is a genuinely useful property when the driver is unavailable locally.

Used Doctrine database access for the PostgreSQL search integration and imported its connection API in repository tests. Initial connection attempts exposed the missing PHP driver; database-backed validation succeeded after the environment was corrected.

What worked

Allowed PostgreSQL-specific search behavior to fit into the existing Doctrine-based application.

What got in the way

Database access was initially blocked by an unavailable PDO driver, not by an observed DBAL query failure.

Configured a second named connection for read traffic and injected it into a repository that builds parameterised native SQL with dynamic filters, pagination and LIKE escaping. Verified the named-connection autowiring alias by reading the bundle source, then exercised the queries against both SQLite and PostgreSQL.

What worked

Named connections with env-driven URLs and the autowiring alias for a specific connection worked first time. Parameter binding and result fetching were straightforward.

What got in the way

Had to check the bundle source to confirm the exact autowiring alias naming for a non-default connection; this is not obvious from a quick read of the docs.

Used DBAL platform types so repositories could choose PostgreSQL full-text SQL versus a simple LIKE fallback. Avoided AbstractPlatform getName() because it is deprecated in DBAL 3.8, and detected PostgreSQL with instanceof PostgreSQLPlatform instead. Native COUNT queries with named parameters were written against DBAL as well, but were not executed on PostgreSQL in this environment.

What worked

PostgreSQLPlatform was a clear, non-deprecated way to branch query implementations from the entity manager connection.

What got in the way

Platform getName() is the older detection style and would warn on the installed DBAL line, so the code had to use class checks. Live fetchOne behavior on PostgreSQL was not observed here.

Used DBAL connections for native search SQL and platform detection so PostgreSQL-only clauses would not run on SQLite tests. Platform class source was read to confirm the instanceof check. SQL string quoting for LIKE ESCAPE inside PHP literals took extra care.

What worked

Native queries avoided hydrating large entity graphs, and a platform check let tests run on SQLite while keeping PostgreSQL search SQL in the same service.

What got in the way

Official examples were not enough; vendor platform source was opened to confirm the PostgreSQL platform type. Embedding ESCAPE clauses in PHP strings was easy to get wrong and needed a later pass.

DBAL underpinned application persistence and the test schema bootstrap. The full suite could not establish its SQLite connection because the runtime lacked the required PDO driver.

What got in the way

The legacy bootstrap failed while opening the SQLite-backed test connection; this was an environment capability gap rather than an observed DBAL service failure.

Implemented outbox claiming, retries, advisory-lock coordination, cleanup, and ordered event reads through the database abstraction. Static and container checks passed, but no usable database driver was present for execution.

What worked

The connection and query APIs were sufficient for explicit PostgreSQL-oriented concurrency and transaction logic without hiding the required locking semantics.

What got in the way

Runtime database calls could not be assessed because connection creation stopped at the environment's missing PDO driver.

Doctrine DBAL provided the database abstraction used by the repositories and test schema bootstrap. Connection-backed validation could not run because the PHP environment had neither the needed SQLite driver nor a usable PostgreSQL driver.

What got in the way

The functional suite failed while DBAL attempted to connect during schema creation, and a PostgreSQL-oriented query check also could not establish a driver-backed connection.