Create a TypeRegistry and enable injection of Type instances

[GromNaN]

Q	A
Type	feature
BC Break	no (deprecation)
Fixed issues	Closes #2818

Summary

• Introduce a new class TypeRegistry that replace the static method of the Type class. The name is the same as DBAL TypeRegistry, with the same methods (except override because register creates or replace the type, "upsert" is a MongoDB specificity 😉)
• Deprecate all the static methods of the Type class
• Inject the TypeRegistry into the Configuration and add the public method getTypeRegistry(). This method is used by UnitOfWork, DocumentPersister and the aggregation builder.
• Inject the TypeRegistry into ClassMetadata instances.

The Bundle PR: doctrine/DoctrineMongoDBBundle#963

[Copilot]

Pull request overview

This PR introduces a new TypeRegistry class to manage type instances and enables dependency injection of Type instances, deprecating the static methods on the Type class. This architectural change improves testability and allows for better isolation of type registries per DocumentManager.

Key changes include:

• Creating TypeRegistry to replace static Type methods
• Injecting TypeRegistry into DocumentManager and ClassMetadata
• Deprecating all static methods on the Type class

Reviewed changes

Copilot reviewed 37 out of 37 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/Types/TypeRegistry.php	New class implementing type registration and retrieval
src/Types/Type.php	Static methods deprecated in favor of TypeRegistry
src/DocumentManager.php	Integration of TypeRegistry with initialization logic
src/Mapping/ClassMetadata.php	TypeRegistry injection and usage for type operations
src/UnitOfWork.php	Updated to use DocumentManager's TypeRegistry
src/Persisters/*.php	Updated to use DocumentManager's TypeRegistry
src/Hydrator/HydratorFactory.php	Updated to use DocumentManager's TypeRegistry
src/Aggregation/*.php	Updated to use DocumentManager's TypeRegistry
tests/Tests/Types/TypeRegistryTest.php	New test coverage for TypeRegistry
tests/Tests/Types/TypeTest.php	Updated tests for deprecated Type methods
tests/Tests/CaptureDeprecationMessages.php	New trait for capturing deprecation messages in tests
tests/**/*Test.php	Test files updated to use TypeRegistry

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[alcaeus]

Initial review done. I like the idea of a type registry, but it once again shows that we really need to clean up the dependency mess that we currently have.
The only concern I have is exposing the convertToDatabase method from DocumentPersister. I think we should mark it as @internal to ensure people don't treat it as part of the public API (unless the whole persister is already marked as such).

[greg0ire]

Should it be final?

[GromNaN]

Then I would have to create an interface since it's not internal. Which is more strict for BC than a regular class.

[greg0ire]

Then I would have to create an interface since it's not internal.

Do you? Is every type supposed to be replacable/mockable? I think it's OK to marks something as final and postpone the decision of making it extensible vs having an interface to when a need for extensibility actually emerges. For something that looks like an map with extra methods, I'm not convinced extensibility is needed.

Feel free to ignore this if you have a hard rule about this in this project.

[alcaeus]

Agree with making it final. We don't need to mock it for internal tests (yet), and people should definitely be mocking it for their own tests considering it's a registry they can create and inject as they see fit. We can always make the class non-final in a future minor release if necessary.

[GromNaN]

I've already a use-case for extending the TypeRegistry: in the bundle I add lazy-loading of type instances from the container: https://github.com/doctrine/DoctrineMongoDBBundle/pull/963/changes#diff-b090a1e775d0625ed9280a9140328e118d6ad52fafb71464bf7246ac937e8442

[greg0ire]

Some commits look like they should be squashed together.

[GromNaN]

Some commits look like they should be squashed together.

Yes, my plan was to have 2 separate commits to ease with rebase and merges, but the implementation changed a lot and that will not help anymore. I'll squash-merge the PR as we usually do on the MongoDB-ODM project.

[alcaeus]

Code LGTM. Do you want to add the deprecations to the UPGRADE document now or do we do that in the 3.0.x branch when we remove deprecated functionality?