Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom datetime with support of microseconds always generate unnecessary migration after update of dbal from 3.6 to 4.2.1 #1472

Closed
bogdandubyk opened this issue Nov 26, 2024 · 1 comment

Comments

@bogdandubyk
Copy link

Bug Report

Q A
BC Break no
Version 3.8.2
dbla version 4.2.1

Summary

I have a custom type

final class DateTimeImmutableMicrosecondsType extends DateTimeTzImmutableType
{
    private const FORMAT = 'Y-m-d H:i:s.u';

    /**
     * @param T $value
     *
     * @return (T is null ? null : string)
     *
     * @throws ConversionException
     *
     * @template T
     */
    public function convertToDatabaseValue(mixed $value, AbstractPlatform $platform): ?string
    {
        if (
            $value instanceof DateTimeImmutable &&
            $platform instanceof PostgreSQLPlatform
        ) {
            return $value->format(self::FORMAT);
        }

        return parent::convertToDatabaseValue($value, $platform);
    }

    /**
     * @param T $value
     *
     * @return (T is null ? null : DateTimeImmutable)
     *
     * @template T
     * @throws InvalidFormat
     */
    public function convertToPHPValue(mixed $value, AbstractPlatform $platform): ?DateTimeImmutable
    {
        if ($value === null || $value instanceof DateTimeImmutable) {
            return $value;
        }

        if ($platform instanceof PostgreSQLPlatform) {
            try {
                $dateTime = DateTimeImmutable::createFromFormat(self::FORMAT, $value);
            } catch (\Throwable) {
                throw InvalidFormat::new(
                    $value,
                    self::class,
                    $platform->getDateTimeTzFormatString(),
                );
            }

            if ($dateTime !== false) {
                return $dateTime;
            }

            throw InvalidFormat::new(
                $value,
                self::class,
                $platform->getDateTimeTzFormatString(),
            );
        }

        return parent::convertToPHPValue($value, $platform);
    }

    /** @param mixed[] $column */
    public function getSQLDeclaration(array $column, AbstractPlatform $platform): string
    {
        if ($platform instanceof PostgreSQLPlatform) {
            return 'TIMESTAMP(6) WITH TIME ZONE';
        }

        return $platform->getDateTimeTzTypeDeclarationSQL($column);
    }
}

in my Symfony app it registered like this

doctrine:
    dbal:
        types:
            datetimetz_immutable: App\Doctrine\Types\DateTimeImmutableMicrosecondsType

and in my XML entity mapping, I use it like this

<field name="updatedAt" type="datetimetz_immutable" column="updated_at" nullable="true"/>

All worked perfectly, diff command generated migration like this:

 updated_at TIMESTAMP(6) WITH TIME ZONE

and added commend like this

'COMMENT ON COLUMN updated_at IS \'(DC2Type:datetimetz_immutable)\''

But now I updated DDBAL to version 4.2.1 and when I run a diff it generates a new migration

        $this->addSql('ALTER TABLE table ALTER updated_at TYPE TIMESTAMP(6) WITH TIME ZONE');
        $this->addSql('COMMENT ON COLUMN updated_at IS \'\'');

First of all for some reason removing comment, and altering table to set same type again :)

Okay, I run that migration and run diff again and it generate migration like this

    $this->addSql('ALTER TABLE table ALTER updated_at TYPE TIMESTAMP(6) WITH TIME ZONE');

So it's always trying to convert type to TIMESTAMP(6) WITH TIME ZONE but that type is already correct one.

Current behavior

Doctrime diff always generating migration like this

    $this->addSql('ALTER TABLE table ALTER updated_at TYPE TIMESTAMP(6) WITH TIME ZONE');

How to reproduce

Have a custom type from above, dbal 4.2.1 and run diff command

@derrabus
Copy link
Member

Duplicate of #1441.

@derrabus derrabus closed this as not planned Won't fix, can't repro, duplicate, stale Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants