Feature request: Add support for TypeFieldMapper

[adrianrudnik]

Since https://github.com/doctrine/orm/pull/10313 we now have a way to extend the automatic mapping of DBAL types.

Similar to \Doctrine\ORM\Configuration::setNamingStrategy there is now \Doctrine\ORM\Configuration::setTypedFieldMapper, which is not yet configurable by this bundle afaik.

It would be nice to have it configurable with a service, so we can extend it, like we have for the naming_strategy.

My current workaround to get custom types injected is rather cumbersome, and I'm not even sure if my way is to complicated and there is a much easier way to achieve this. I had to circumvent a lot of private service dependencies to get near the configuration stuff, while preserving all injections:

# services.php

$services->set('app.typed_field_mapper', DefaultTypedFieldMapper::class)
    ->args([[CustomField::class => 'customfield']]);

$services->set(Doctrine\ORM\Configuration::class)
    ->public()
    ->decorate('doctrine.orm.default_configuration', 'doctrine.orm.default_configuration.inner')
    ->parent('doctrine.orm.default_configuration')
    ->call('setTypedFieldMapper', [service('app.typed_field_mapper')]);

[nicolas-grekas]

I'd also like to be able to do this. In addition (or instead?) of configuring a service, this could support configuring the mapping directly:

doctrine:
    orm:
        typed_fields:
            App\My\CustomType: my_type

Up to give it a try @adrianrudnik?

[adrianrudnik]

@nicolas-grekas I hope I might have a free slot next week.

I always get confused with this topic as doctrine.dbal.types is one-sided and not done in reverse. Not sure it would be actually in the ORM part of the configuration, what do you think?

Example for Symfony:

doctrine:
    dbal:
        mapping_types:
            mycustom: MyCustomType::class

should this not be enough to auto-register stuff for the column definition so that @ORM\Column without a type is correctly mapped to MyCustomType::class if the column type is mycustom and also considered by the SchemaTool to correctly create i.e. doctrine migrations using the correct type (right now it would create a varchar[255] for my type and not consider my registered one)?

For me mycustom is currently (in postgres):

CREATE DOMAIN mycustom AS JSONB;

Looking at your PR, as far as I can understand it quickly, you want to "override" the hard mapping for \DateTime, \DateTimeImmutable and \DateInterval correct? Something like

doctrine:
    dbal:
        mapping_types:
            date_immutable: \Symfony\Component\Clock\DateTime::class
            time_immutable: \Symfony\Component\Clock\DateTime::class
            datetime_immutable: \Symfony\Component\Clock\DateTime::class
            datetimetz_immutable: \Symfony\Component\Clock\DateTime::class

            # if you want to refactor an app that should never use non-immutables anymore
            datetime: \Symfony\Component\Clock\DateTime::class

All _immutables could be overriden by the framework itself, the last one could be done by the user if he wants to enforce immutables?

Not sure I'm getting all of this correctly, just trying to find a common ground.

[nicolas-grekas]

TypeFieldMapper is in the Orm namespace, that's why it should be under doctrine.orm. It provides a mapping from the type on properties to the column type. That's in ORM because it's a way to define the metadata mapping.

In my case, I would:

• map properties of type Clock\DateTime to the datetime_immutable type for the ORM side
• map datetime_immutable to Clock\Doctrine\DateTimeType (to be created) so that all objects get this instead of the native one

[adrianrudnik]

Ah I see, yes, TypeFieldMapper is indeed in the ORM namespace, getting a bit confused over here.

[ostrolucky]

Related: #1595

PR welcome

[0x346e3730]

Bumping this as DatePoint is released but cannot be used as an entity's propriety for now. I would love to do a PR but I only see how to add typed_fields into the config and don't see where to add doctrine's TypeFieldMapper inside the bundle.