Add #[AsDbalType] attribute

[syl20b]

Description

This PR add a new #[AsDbalType] attribute to automatically register the related class as a DBAL type.

Problem Solved

Currently, to register a custom DBAL type, it must be manually declared in the Doctrine configuration file:

# config/packages/doctrine.yaml

doctrine:
    dbal:
        types:
            my_custom_type: App\Type\MyCustomType

This approach is verbose and requires the developer to manage configuration in addition to the type class itself.

Feature Added

The addition of the #[AsDbalType] attribute allows the application to automatically detect and register any class that uses this attribute.

---

Concrete Usage Example

Here is how you can register a custom type directly via the attribute, without touching the YAML configuration:

1. Creating the Custom Type

<?php

namespace App\Type;

use Doctrine\DBAL\Types\Type;
use Doctrine\DBAL\Platforms\AbstractPlatform;
use Doctrine\Bundle\DoctrineBundle\Attribute\AsDoctrineType;

#[AsDbalType(name: 'my_custom_type')]
final class MyCustomType extends Type
{
    // ... implementation of methods
}

2. Usage in an Entity

You can then use this type directly in your entities:

<?php

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

class Product
{
    #[ORM\Column(type: 'my_custom_type', length: 255)]
    private ?string $name = null;
    
    // ...
}

Advantages

• Zero Configuration: No need to modify doctrine.yaml for every new custom type.
• Discoverability: The DBAL type and its name are declared in the same location as its implementation.

[syl20b]

@stof is it ok for you?

[silasjoisten]

I think this PR belongs more into the symfony/doctrine-bridge and there is already a PR for this: symfony/symfony#63774

[syl20b]

@silasjoisten

I think this PR belongs more into the symfony/doctrine-bridge and there is already a PR for this: symfony/symfony#63774

AFAIK, the bridge aims to do a bridge between a Symfony component and Doctrine, but this feature is not related to a Symfony component, so it should belongs to the bundle IMHO

[silasjoisten]

I’m not fully convinced this should live in the bundle.

According to the Symfony docs, DoctrineBridge is meant to “provide integration for Doctrine with Symfony components”, while DoctrineBundle mainly handles configuration and wiring.

This change feels more like integration logic (how Symfony registers and discovers Doctrine types) rather than something that should be driven by bundle configuration.

We already keep things like Doctrine types and Symfony specific behavior in the Bridge, so moving the registration logic there would keep responsibilities more clearly separated and consistent with existing patterns.

Otherwise we risk spreading behavior across both layers, which makes it harder to reason about and reuse outside of a full DoctrineBundle setup.

[syl20b]

@silasjoisten

According to the Symfony docs, DoctrineBridge is meant to “provide integration for Doctrine with Symfony components”, while DoctrineBundle mainly handles configuration and wiring.

I agree with that, but there is no component involved here

This change feels more like integration logic (how Symfony registers and discovers Doctrine types) rather than something that should be driven by bundle configuration.
We already keep things like Doctrine types and Symfony specific behavior in the Bridge, so moving the registration logic there would keep responsibilities more clearly separated and consistent with existing patterns.

Types you mention are Symfony component related types (Uid, Clock,...)

[syl20b]

@greg0ire What do you think about that ?

[greg0ire]

I agree with you, and furthermore, there are other attributes already: https://github.com/doctrine/DoctrineBundle/tree/3.2.x/src/Attribute

[greg0ire]

Should this come with docs?

[syl20b]

Should this come with docs?

@greg0ire Documentation added ;)

[greg0ire]

To be squash-merged

[syl20b]

@greg0ire commits squashed 👍

[GromNaN]

I'm working on this topic using a TypeRegistry per connection, so that we can leverage dependency injection.

• Add TypeRegistry to Configuration and use it in all internal type resolution dbal#7342
• Replace static Type::* calls with instance-based TypeRegistry lookups orm#12421

I want to give a more advanced review before we introduce a solution that will be updated.

In any case, I think it is useful to have an attribute like #[AsType] or #[AsDatabaseType] to specify the type name and the connection or entity manager to which it should be associated.

[syl20b]

I'm working on this topic using a TypeRegistry per connection, so that we can leverage dependency injection.

• Add TypeRegistry to Configuration and use it in all internal type resolution dbal#7342
• Replace static Type::* calls with instance-based TypeRegistry lookups orm#12421

I want to give a more advanced review before we introduce a solution that will be updated.

In any case, I think it is useful to have an attribute like #[AsType] or #[AsDatabaseType] to specify the type name and the connection or entity manager to which it should be associated.

@GromNaN I love the idea of being able to configure types per connection and having them potentially registered as services. The migration path might be long and could be split into several small steps :

1. Add an #[AsDatabaseType] attribute to improve DX, based on the existing feature (what this PR is supposed to do)
2. Modify DBAL to enable types per connection configuration (which seem to be implemented in the 2 PRs above)
3. Integrate this evolution into the bundle
4. Allow custom types to be defined/registered as services

WDYT ?

I would be happy to help.

In the meantime, I reworked my first implementation to make the attribute name optional, and I renamed the attribute as proposed.

[SenseException]

I believe 3.2.0 isn't the correct branch anymore because this is a new feature.

[GromNaN]

That sounds great to me. We'll have to tweak the mechanics for #2221, but without any breaking changes.

[syl20b]

@GromNaN Is it good for you ? Can I squash my commits ?

[syl20b]

@GromNaN Commits squashed. Many thanks ;)

[syl20b]

@greg0ire @SenseException is it still Ok for you?

[GromNaN]

Thank you @syl20b