feat: 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,...)