Enable service injection for custom field types and `#[AsFieldType]` attribute by GromNaN · Pull Request #963 · doctrine/DoctrineMongoDBBundle

GromNaN · 2025-12-10T06:50:10Z

Bundle implementation of the TypeRegistry from doctrine/mongodb-odm#2966

In order to preserve BC in case people manipulate types with the methods such as Type::add(), we use the singleton TypeRegistry::getSharedInstance().

The new option doctrine_mongodb.type_registry enables a single instance of TypeRegistry per DocumentManager, and the autoconfiguration of services with the #[AsFieldType] attribute.

#[AsFieldType(Money::class, objectManager: 'customer_manager')]
final class MoneyType extends Type
{
    // ...
}

This feature is very powerful, combined with the detection of the Field type from the property type.

use Money\Money;
use Doctrine\ODM\MongoDB\Mapping\Annotations as ODM;

#[ODM\Document]
class Product
{
    #[ODM\Id]
    public ?string $id = null;

    #[ODM\Field]
    public Money $price;
}

Copilot

Pull request overview

This PR enables service injection for custom field types by implementing a TypeRegistry system with per-DocumentManager type registries and autoconfiguration support via the #[AsFieldType] attribute. The implementation allows custom field types to be registered as services and automatically detected through attributes, while maintaining backward compatibility with the existing singleton approach.

Key Changes:

Adds type_registry configuration option to enable per-DocumentManager type registries
Implements service-based type registration through the #[AsFieldType] attribute
Introduces LazyTypeRegistry for lazy-loading types from a service locator

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/Attribute/AsFieldType.php	New attribute class for marking MongoDB ODM field types with autoconfiguration support
src/Types/LazyTypeRegistry.php	Lazy-loading type registry that extends TypeRegistry and uses Symfony's ServiceLocator
src/DependencyInjection/Compiler/TypeRegistryPass.php	Compiler pass that processes tagged services and builds per-manager type registries
src/DependencyInjection/Configuration.php	Adds `type_registry` boolean option and supports service-based type definitions
src/DependencyInjection/DoctrineMongoDBExtension.php	Registers type registry services and handles custom type configuration
src/ManagerConfigurator.php	Updates type loading to support both TypeRegistry and legacy Type::addType() approaches
src/DoctrineMongoDBBundle.php	Registers TypeRegistryPass compiler pass and adds proxy autoloader check
docs/cookbook/field_type.rst	New documentation for registering custom field types with examples
docs/config.rst	Updated configuration documentation with service-based type examples
config/schema/mongodb-1.0.xsd	Schema updates to support optional class attribute and new service attribute
tests/*	Test fixtures and assertions for the new type registry functionality
phpstan-baseline.neon	Updated baseline for new type-related PHPStan issues

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

greg0ire · 2025-12-10T16:26:17Z

                ->end()
+                ->booleanNode('type_registry')
+                    ->defaultFalse()
+                    ->info('If true, create a distinct TypeRegistry for each DocumentManager and inject services tagged with "doctrine_mongodb.field_type". If false, use a shared TypeRegistry for all DocumentManagers.')


Suggested change

->info('If true, create a distinct TypeRegistry for each DocumentManager and inject services tagged with "doctrine_mongodb.field_type". If false, use a shared TypeRegistry for all DocumentManagers.')

->info('If true, create a distinct TypeRegistry for each DocumentManager and inject services tagged with "doctrine_mongodb.field_type" in them. If false, use a shared TypeRegistry for all DocumentManagers.')

So when this is set to false, there is still a TypeRegistry? This is confusing…

There is always a TypeRegistry instance, but in one case it's the global shared one (for BC) and when the option is enabled it's 1 instance per document manager.

Do you find a better name for this option?

Maybe global_type_registry? Or shared_type_registry?

That was my initial idea, but I would like this option to be false by default. So, something like types_per_manager.

I think you mean true by default, and I thought about this too, so I thought about specific_type_registry or per_dm_type_registry, none of which sound very appealing. If maybe global type registries are going to be deprecated, then I wouldn't sweat it and accept this situation. It's IMO better than an ambiguous setting name.

If I ask Claude, It comes up with:

isolated_type_registries

scoped_type_registry

separate_type_registries

type_registry_scope (enum-style)

enable_per_manager_types

type_registry_isolation

I think only scoped_type_registry is appealing. What do you think?

greg0ire · 2025-12-10T16:27:01Z

+
+            return $typeConfig;
+        }, $config['types'] ?? []);
+        if (! $config['type_registry']) {


Is there a reason to use negative logic here?

I started with a flag meaning the opposite, that's why it's negative here and the description is confusing. I'll fix that.

…o the Configuration

alcaeus · 2025-12-16T11:43:03Z

                        })
                    ->end()
                ->end()
+                ->booleanNode('scoped_type_registry')


Unless we already have a distinct use case for scoped registries, I'd prefer not adding another config setting for this. Using multiple document managers is already dodgy enough, I wouldn't want to add extra complexity.

This is mainly a backward compatibility issue. Currently, people can add types using the static Type::register() anywhere is their code.

Without this option. This option will be deprecated in the next major version. We will always have 1 instance of TypeRegistry per DocumentManager.

But, instead I can detect when services are used as type to enable the feature.

alcaeus · 2025-12-16T11:44:39Z

+
+    public function has(string $name): bool
+    {
+        return $this->locator->has($name) || parent::has($name);


I assume there's no significant performance difference between the two (as both are essentially maps connecting a string to an object), so the order of operations does not matter here.

Indeed, default types are a lot more used than the custom ones.

Suggested change

return $this->locator->has($name) || parent::has($name);

return parent::has($name) || $this->locator->has($name);

alcaeus · 2025-12-16T11:45:16Z

+        if ($this->locator->has($name)) {
+            return $this->locator->get($name);
+        }


Similar to the comment above, I assume there's no performance issue with checking for a service in the locator or repeatedly fetching the same service from it.

This is the feature: we can override the default types this way.

alcaeus · 2025-12-16T11:45:53Z

    private function registerAutoloader(DocumentManager $documentManager): void
    {
        $configuration = $documentManager->getConfiguration();
+        if ($configuration->isLazyGhostObjectEnabled() || $configuration->isNativeLazyObjectEnabled()) {


Should this be an optimisation or bug fix in a separate PR? No strong feelings, it just seems out of place in this PR.

alcaeus · 2025-12-16T11:47:14Z

+    #[AsFieldType(Money::class)]
+    final class MoneyType extends Type
+    {
+        // This trait provides a default closureToPHP() used to generate data hydratation classes


Suggested change

// This trait provides a default closureToPHP() used to generate data hydratation classes

// This trait provides a default closureToPHP() used to generate data hydration classes

alcaeus · 2025-12-16T11:49:31Z

+
+    private const TAG = 'doctrine_mongodb.odm.field_type';
+
+    private const ALL = '\0';


I'll note that this is not actually a null byte, but rather the literal string \0. I would hope people don't actually use that.

Null byte is better, isn't it?

Suggested change

private const ALL = '\0';

private const ALL = "\0";

But this can be anything that is not a valid document manager name.

GromNaN · 2025-12-16T13:09:43Z

                        ->children()
-                            ->scalarNode('class')->isRequired()->end()
+                            ->scalarNode('class')->end()
+                            ->scalarNode('service')->end()


I will remove this new configuration. As a service needs to be already registered, adding a tag to the service is the way to register it. And the new #[AsFieldType] attribute makes it easy.

GromNaN added this to the 5.6.0 milestone Dec 10, 2025

GromNaN requested review from alcaeus and Copilot December 10, 2025 06:50

GromNaN added the Feature label Dec 10, 2025

GromNaN force-pushed the type-registry branch from 927a0c8 to e333c1a Compare December 10, 2025 06:50

Copilot AI reviewed Dec 10, 2025

View reviewed changes

Comment thread docs/config.rst Outdated

Comment thread docs/config.rst Outdated

Comment thread docs/config.rst Outdated

Comment thread docs/config.rst Outdated

Comment thread docs/cookbook/field_type.rst Outdated

GromNaN requested a review from IonBazan December 10, 2025 06:57

GromNaN force-pushed the type-registry branch from e333c1a to 874adfa Compare December 10, 2025 07:01

This was referenced Dec 10, 2025

Create a TypeRegistry and enable injection of Type instances doctrine/mongodb-odm#2966

Open

Extract the static methods of the Type class into a TypeRegistry service doctrine/mongodb-odm#2818

Open

GromNaN requested a review from greg0ire December 10, 2025 14:15

greg0ire reviewed Dec 10, 2025

View reviewed changes

GromNaN added 2 commits December 10, 2025 18:28

Enable service injection for custom field types

b78cd0f

Add autoconfiguration of custom field types using an attribute

5a1509f

GromNaN force-pushed the type-registry branch from 874adfa to 5a1509f Compare December 10, 2025 17:37

Rename option to scoped_type_registry and inject the TypeRegistry int…

c73983f

…o the Configuration

alcaeus reviewed Dec 16, 2025

View reviewed changes

GromNaN commented Dec 16, 2025

View reviewed changes

GromNaN removed this from the 5.6.0 milestone Jan 26, 2026

	->info('If true, create a distinct TypeRegistry for each DocumentManager and inject services tagged with "doctrine_mongodb.field_type". If false, use a shared TypeRegistry for all DocumentManagers.')
	->info('If true, create a distinct TypeRegistry for each DocumentManager and inject services tagged with "doctrine_mongodb.field_type" in them. If false, use a shared TypeRegistry for all DocumentManagers.')

	return $this->locator->has($name) \|\| parent::has($name);
	return parent::has($name) \|\| $this->locator->has($name);

	// This trait provides a default closureToPHP() used to generate data hydratation classes
	// This trait provides a default closureToPHP() used to generate data hydration classes


		private const TAG = 'doctrine_mongodb.odm.field_type';

		private const ALL = '\0';

Conversation

GromNaN commented Dec 10, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greg0ire Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GromNaN Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

greg0ire Dec 10, 2025 •

edited

Loading

GromNaN Dec 10, 2025 •

edited

Loading