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

Unable to instantiate Schema objects without deprecations #6737

Closed
xabbuh opened this issue Jan 24, 2025 · 4 comments · Fixed by #6739
Closed

Unable to instantiate Schema objects without deprecations #6737

xabbuh opened this issue Jan 24, 2025 · 4 comments · Fixed by #6739

Comments

@xabbuh
Copy link
Member

xabbuh commented Jan 24, 2025

Bug Report

Q A
Version 4.3.x
Previous Version if the bug is a regression

Summary

It looks like with the changes from #6734 it would currently not be possible with Doctrine DBAL 4.3 to create Schema instances without triggering deprecations. I talked with @greg0ire about this on Slack and he suggested that this might be an oversight and switching to triggerIfCalledFromOutside() when issuing the deprecation or adding an exception there if $this is an instance of Schema could be possible solutions.

Current behavior

Expected behavior

Constructing Schema objects should be possible without deprecations.

How to reproduce

see https://github.com/symfony/symfony/actions/runs/12953164049/job/36132194682#step:9:1211

@greg0ire
Copy link
Member

@morozov can you please look into this?

@morozov
Copy link
Member

morozov commented Jan 25, 2025

We probably need to backport this method which I introduced only during the merge up in #6735:

dbal/src/Schema/Schema.php

Lines 130 to 138 in c7877f3

/**
* The object representation of the name isn't used because {@see Schema} is not an {@see AbstractAsset}.
*
* This method implements the abstract method in the parent class and will be removed once {@see Schema} stops
* extending {@see AbstractAsset}.
*/
protected function setName(?Name $name): void
{
}

@morozov
Copy link
Member

morozov commented Jan 25, 2025

@xabbuh thanks for pointing out the regression. Unlike API consumers (e.g. Symfony) which indent to stay deprecation-free, the library itself must execute some deprecated code paths for backward compatibility (not in this case, though). Because of that, it is hard to imagine a way for us to make sure that the deprecation notices are only triggered when they are supposed to.

It is really great that there's a 3rd-party test suite that can find such regressions. What would be the easiest way to run this test suite locally to confirm that no similar regressions are introduced in the future?

@morozov morozov linked a pull request Jan 25, 2025 that will close this issue
@xabbuh
Copy link
Member Author

xabbuh commented Jan 27, 2025

@morozov Twig runs Drupal tests. Maybe you could take inspiration from it: https://github.com/twigphp/Twig/blob/3.x/tests/drupal_test.sh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants