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

[idea] reactor to migrate from the deprecated constants of \Doctrine\DBAL\Types\Type #2280

Closed
stof opened this issue Nov 7, 2019 · 2 comments · Fixed by #2514
Closed

[idea] reactor to migrate from the deprecated constants of \Doctrine\DBAL\Types\Type #2280

stof opened this issue Nov 7, 2019 · 2 comments · Fixed by #2514

Comments

@stof
Copy link

stof commented Nov 7, 2019

Doctrine DBAL 2.10 is deprecating the constants in the \Doctrine\DBAL\Types\Type abstract class in favor of equivalent constants in \Doctrine\DBAL\Types\Types (most constants have the same name, but a few of the date-related types have _MUTABLE added in the constant name to make them symmetric with the _IMMUTABLE date types);

Diff

 use Doctrine\DBAL\Types\Type;
+use Doctrine\DBAL\Types\Type;

-$query->setParameter($a, Type::BOOLEAN);
-$query->setParameter($b, Type::DATE);
+$query->setParameter($a, Types::BOOLEAN);
+$query->setParameter($b, Types::DATE_MUTABLE);

Removing the existing use statement for Doctrine\DBAL\Types\Type might a nice bonus, but it requires to be careful (as it could be used for other things than referencing constants), and PHP-CS-Fixer can already be used to clean that after the migration anyway.

@stof stof changed the title [idea] reactor to migrate from the deprecate constants of \Doctrine\DBAL\Types\Type [idea] reactor to migrate from the deprecated constants of \Doctrine\DBAL\Types\Type Nov 7, 2019
@TomasVotruba
Copy link
Member

I overlooked this issues, just getting to it now.

I wonder if it would be more useful to cover whole https://github.com/doctrine/dbal/blob/master/UPGRADE.md, where possible

@TomasVotruba
Copy link
Member

It's very hard to deduce migration path from the upgrade file, as FQN classes are missing and wording is often ambiguous. Diff examples would be more helpful.

I've started first set at #2514
I'd be happy if you check it and fix/complete, if you find a way

TomasVotruba added a commit that referenced this issue May 10, 2022
rectorphp/rector-src@1dd739a Update RemoveAlwaysTrueConditionSetInConstructorRector to return stmts (#2280)
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

Successfully merging a pull request may close this issue.

2 participants