Add TypeRegistry to Configuration and use it in all internal type resolution

[GromNaN]

Q	A
Type	feature
Fixed issues	-

Continues #6705. The existing TypeRegistry class already supports scoped, instance-based
type management; this PR wires it into the rest of DBAL so it is actually used.

Companion PRs: doctrine/orm#12421 and doctrine/DoctrineBundle#2221.
This is already being done in the same way for Doctrine MongoDB ODM: doctrine/mongodb-odm#2966

#7490 is merged into this branch so the whole direction is visible in one place. I recommend
merging #7490 first, then rebasing this PR on top of it.

Disclamer: This PR was made using Claude under my very close supervision; trying to provide a more detailed description of the changes than I would have written myself, but I have verified the content and made some edits for clarity and accuracy.

Motivation

Two goals:

• Dependency injection into type instances. Custom types sometimes need access to
  services (e.g. a serializer, an encryption service). With the global static registry this is impossible
  without static state. A per-connection type provider can hold fully-constructed type
  instances.

• Prevent global side-effects. Type::addType() and Type::overrideType() mutate a
  process-wide singleton, so a test or a bundle changing a type affects every connection.
  A scoped provider isolates those changes.

What changed

TypeProvider

New interface, and the type Configuration now expresses:

interface TypeProvider extends Traversable
{
    public function get(string $name): Type;

    public function has(string $name): bool;
}

It extends Traversable, since callers may also want to enumerate the available types.
register() and override() are deliberately absent, so Type::getTypeRegistry() keeps
returning the concrete TypeRegistry that Type::addType() needs.

Extending PSR-11 ContainerInterface was considered and left out for now, since it would make
psr/container a hard requirement. It can still be added later.

TypeRegistry

• Built-in types are pre-populated: new TypeRegistry() already contains all of them. They are
  read straight from a class constant rather than copied per instance, so construction is cheap.
  Custom types passed to the constructor are layered on top and may override built-ins by name.
• Types can be lazy-loaded from a PSR-11 container, given a map of type names to service IDs.
  The container is never queried during construction, nor by has():

  new TypeRegistry($container, ['money' => 'app.dbal_type.money']);

• Implements IteratorAggregate with a generator, replacing the @internal getMap(). Stopping
  early no longer instantiates every remaining type.
• lookupName() is deprecated. It cannot go yet, because the deprecated Column::setType(),
  ColumnEditor::setType() and ORM's TypedExpression still need instance-to-name. It is removed
  in 5.0, together with the restriction that an instance may only be registered under one name.

Configuration

• getTypeProvider(): TypeProvider returns the provider for this connection, lazily defaulting
  to the global registry (Type::getTypeRegistry()).
• setTypeProvider(TypeProvider $provider): self injects a provider scoped to this connection.

Internal type resolution

All of the following now resolve types through $configuration->getTypeProvider() instead
of the static Type::* methods:

Component	Method(s) changed
Connection	convertToDatabaseValue(), convertToPHPValue(), getBindingInfo()
Statement	parameter binding
AbstractPlatform	initializeAllDoctrineTypeMappings(), registerDoctrineTypeMapping(), getType()
*SchemaManager (×6)	_getPortableTableColumnDefinition()
*MetadataProvider (×6)	column type resolution

AbstractPlatform receives its Configuration via a new setConfiguration() method
called by Connection::getDatabasePlatform() after platform creation.

Because #7490 makes Column store a type name rather than an instance, the schema managers hand
the name straight to Column and no longer resolve a Type first. Table, Schema and
SchemaConfig therefore need no provider at all.

The static Type::* methods are deprecated

They all operate on the process-wide registry, which behaves unexpectedly as soon as a connection
has its own type provider: a type registered with Type::addType() is invisible to that
connection, and Type::getType() resolves against the global registry rather than the
connection's. Nothing signalled that today, so the mistake surfaced later as an apparently
unrelated UnknownColumnType.

getTypeRegistry(), getType(), addType(), hasType(), overrideType(),
getTypesMap() and lookupName() therefore carry an @deprecated docblock and a runtime
deprecation. They keep working and still delegate to the global registry, so nothing breaks.

getTypeRegistry() and getType() use triggerIfCalledFromOutside, because
Configuration::getTypeProvider(), AbstractPlatform and the deprecated Column::getType()
call them internally: the supported default path stays silent, and a single user call is not
reported twice.

DBAL 5 will have no static type provider.

Trade-offs

Iterating a provider resolves every type. AbstractPlatform::initializeAllDoctrineTypeMappings()
does exactly that, so schema introspection instantiates all types. Laziness holds for query paths.

Custom types registered via Type::addType() are invisible to connections that use a
custom provider. This is intentional: it is the isolation the feature provides.
Users who set a provider are responsible for registering all types they need in it.

The global singleton is preserved. Type::getTypeRegistry() still returns the
process-wide registry. Connections that do not call setTypeProvider() continue to behave
exactly as before.

[stof]

As discussed during the SymfonyLive, it would be great to support lazy-loading of type instances injected in the TypeRegistry, to reduce the cost of instantiation the connection service (especially when types have dependencies, which might lead to instantiating a bigger object graph).

As far as DoctrineBundle is concerned, the easier way would probably involve injecting a PSR-12 ContainerInterface (with ids being the type names) and a list of type names (or a map of type names to ids in the container to allow more flexibility about those ids). This would allow us to use the Symfony ServiceLocator which performs such lazy-loading (it would of course mean that the constructor should not retrieve type instances, as that would defeat the lazy-loading).
An alternative implementation could be to use \Symfony\Contracts\Service\ServiceProviderInterface which avoids the need for the separate list of available ids (as the getProvidedServices method allows introspecting the container) but this would introduce a dependency on symfony/service-contracts which might be an issue for other frameworks.

[GromNaN]

Thanks for the reminder @stof!

I implemented both approaches:

• Symfony ServiceProviderInterface (from symfony/service-contracts, added as an optional require-dev dependency): pass it directly as the constructor argument. getProvidedServices() is called during construction to register factory entries lazily — no type instances are created until the first get() call.

• PSR ContainerInterface: pass an array<string, ContainerInterface> where each key is the type name and the value is a container that resolves it. This avoids the symfony/service-contracts dependency entirely.

Both paths converge into a unified $factories array (array<string, class-string<Type>|ContainerInterface>) that also handles built-in types lazily. DoctrineBundle can pass a Symfony ServiceLocator either as a ServiceProviderInterface (preferred) or as individual ContainerInterface entries in the array.

[stof]

I find it weird to pass multiple ContainerInterface. A single container can hold all the types (under different indexes).
My proposal was to have separate arguments to pass a ContainerInterface and a list of ids in it.

[stof]

@GromNaN do you plan to change the way the case of a ContainerInterface gets supported ? See my previous comment that was not answered from April.

[GromNaN]

I reworked the container injection following @stof's review.

TypeRegistry now takes a PSR-11 ContainerInterface plus an explicit map of type names to service IDs, instead of the previous array<string, ContainerInterface>:

$registry = new TypeRegistry($container, ['money' => 'app.dbal_type.money']);

The ServiceProviderInterface special case is gone, so src/ no longer references symfony/service-contracts, and psr/container is only a dev dependency. Besides the dependency, requiring the map removes a footgun: deriving the type names from getProvidedServices() silently assumed that the locator keys were type names, so keying a locator by service ID would have registered service IDs as type names.

The container is never queried during construction, nor by has(), so types remain lazy.

This does not add complexity on the bundle side. doctrine/DoctrineBundle#2221 is updated accordingly: the ServiceLocator is still keyed by type name, so the map is simply an identity map.

I also merged #7490 into this branch, to give a complete picture of where this is heading. Storing a type name on Column removes the need to resolve a Type instance in the schema managers, which in turn let me drop the TypeRegistry propagation through SchemaConfig and Table entirely. It also supersedes the ColumnDiff::hasTypeChanged() trade-off listed in the description: comparing type names detects a change between two names that share a single class, without requiring both sides of the diff to resolve from the same registry.

I recommend merging #7490 first, then rebasing this PR on top of it.

[GromNaN]

Deprecated all the static Type::* methods: mixed with a per-connection type provider they give unexpected results, since a type registered globally is invisible to a connection that has its own provider.

They keep working, and the supported default path stays silent. DBAL 5 will have no static type provider.