Autoconfigure DBAL types

[GromNaN]

Feature Request

What

When a project implements a Doctrine\DBAL\Types\Type, it's almost certain this needs to be declared in the configuration. Using ContainerBuilder::registerForAutoconfiguration(), it should be possible to automatically detect and register this classes.

Why

Remove some obvious configuration.

DoctrineBundle/docs/en/configuration.rst

Lines 883 to 884 in a5f5613

	types:
	custom: Acme\HelloBundle\MyCustomType

How

• In DoctrineExtension, call $this->registerForAutoconfiguration() to add a tag.
• Add a compiler pass that find service by tag name and append the classes names to the doctrine.dbal.connection_factory.types parameter.

Types are not scoped to the DBAL connection.

[stof]

The reason this was not done is because defining types as services is what does not actually work (DBAL does not support using instances of types that are instantiated externally, and so we cannot make it use the instance instantiated by the container, which could have dependencies and so on).

Adding support for autoconfiguring a service as defining a type would encourage projects to register their types as services, but it would then make developers think that they can use any feature of the DI component for those services.

[GromNaN]

So we need a mechanism in Symfony to discover non-service classes, while ensuring that they are excluded from the DIC. And, if possible, throw an exception when we detect that they are trying to use them as service (let's discuss here symfony/symfony#59704).

The Doctrine\DBAL\Types\Type class has a final constructor, which makes dependency injection more difficult, although someone could try to use injection via a method.

[GromNaN]

Have you ever considered enabling dependency injection for DBAL types?

Using Type::getTypeRegistry()->register($name, $instance), it's possible to set an instance of Type instead of relying on Type::addType($name, $className) to instantiate the class.
Then ConnectionFactory can get a list of array{class:string}|Type and inject the instances when provided.

    private function initializeTypes(): void
    {
        foreach ($this->typesConfig as $typeName => $typeConfig) {
            if ($typeConfig instanceof Type) {
                if (Type::hasType($typeName)) {
                    Type::getTypeRegistry()->override($typeName, $typeConfig);
                } else {
                    Type::getTypeRegistry()->register($typeName, $typeConfig);
                }
            } else {
                if (Type::hasType($typeName)) {
                    Type::overrideType($typeName, $typeConfig['class']);
                } else {
                    Type::addType($typeName, $typeConfig['class']);
                }
            }
        }

[stof]

Well, as long as Type has a final constructor enforcing that it has no arguments, it makes it hard to use proper DI.

[andrew-demb]

See this PR [1] to make the Type constructor not final

[1] doctrine/dbal#6705

[GromNaN]

Property or setter injections are still possible. That could evolve if we add a TypeInterface or remove the constructor constraint.

Even without DI, which was not the main idea behind this issue, that makes the auto-configuration of Type classes possible; and they would be services, as expected.