[hipsterjazzbo]

Context

This is a draft implementation of #2325. I'd appreciate feedback on the approach before considering it ready.

Currently, DatabaseInitializer creates and registers its own PDOConnection, potentially replacing an application-provided Connection. ConnectionInitializer has a separate cache and only handles the default database configuration. GenericDatabase also relies on a config property that isn't part of the Connection interface.

Proposed change

• Resolve connections through the container, respecting existing bindings and database tags.
• Consolidate default PDO connection creation and caching in ConnectionInitializer.
• Pass DatabaseConfig explicitly to GenericDatabase, retaining compatibility with existing constructor calls.
• Honour injected connections in the testing database initializer.
• Add regression coverage for resolution order, tagged databases, connection caching and externally managed transactions.

Design choice — feedback welcome

I initially considered converting ConnectionInitializer directly into a DynamicInitializer. That would be slightly less code, but would change its existing public initialize(Container $container) method signature.

Instead, this implementation preserves that signature and introduces a small TaggedConnectionInitializer that delegates to the same connection-resolution logic.

It's an extra class, but avoids changing an existing public method contract in a 3.x bug fix.

Does that seem like the right trade-off, or would you prefer the direct dynamic-initializer approach? Is there a simpler option I've overlooked?

I'm happy to revise this based on feedback. I'm deliberately leaving Doctrine DBAL integration and the broader v4 database refactor out of scope.

Closes #2325

[brendt]

I initially considered converting ConnectionInitializer directly into a DynamicInitializer. That would be slightly less code, but would change its existing public initialize(Container $container) method signature.

Instead, this implementation preserves that signature and introduces a small TaggedConnectionInitializer that delegates to the same connection-resolution logic.

It's an extra class, but avoids changing an existing public method contract in a 3.x bug fix.

This reasoning doesn't make sense, as Tempest's initializers will never be called directly, we can safely change a normal initializer to a dynamic one in a patch release

[hipsterjazzbo]

Agreed, thanks — I was overvaluing the old Initializer method signature here.

I've updated the PR to make ConnectionInitializer implement DynamicInitializer directly for both tagged and untagged Connection resolution, removed TaggedConnectionInitializer, and updated the container integration test to register just the one initializer.