Postpone deprecation of string representation of order #403
Conversation
tests/CriteriaTest.php
Outdated
| public function testPassingNonOrderEnumToOrderByIsDeprecated(): void | ||
| { | ||
| $this->expectDeprecationWithIdentifier('https://github.com/doctrine/collections/pull/389'); | ||
| $criteria = Criteria::create()->orderBy(['foo' => 'ASC']); | ||
| } | ||
|
|
||
| public function testConstructingCriteriaWithNonOrderEnumIsDeprecated(): void | ||
| { | ||
| $this->expectDeprecationWithIdentifier('https://github.com/doctrine/collections/pull/389'); | ||
| $criteria = new Criteria(null, ['foo' => 'ASC']); | ||
| } | ||
|
|
||
| public function testUsingOrderEnumIsTheRightWay(): void | ||
| { | ||
| $this->expectNoDeprecationWithIdentifier('https://github.com/doctrine/collections/pull/389'); | ||
| Criteria::create()->orderBy(['foo' => Order::Ascending]); | ||
| new Criteria(null, ['foo' => Order::Ascending]); | ||
| } | ||
|
|
||
| public function testCallingGetOrderingsIsDeprecated(): void | ||
| { | ||
| $criteria = Criteria::create()->orderBy(['foo' => Order::Ascending]); | ||
| $this->expectDeprecationWithIdentifier('https://github.com/doctrine/collections/pull/389'); | ||
| $criteria->getOrderings(); | ||
| } |
There was a problem hiding this comment.
Even if you take back the deprecation, those execution paths still have to be tested.
|
I not convinced we need to take back the deprecation. Why can't it be fixed downstream? |
greg0ire
force-pushed
the
postpone-deprecations
branch
from
3062d2a
to
8fb3eae
Compare
|
After reading doctrine/orm#11313 (comment), I believe it would imply changing, among other things, the signature of - public function addOrderBy(string|Expr\OrderBy $sort, string|null $order = null): static
+ public function addOrderBy(string|Expr\OrderBy $sort, Order|string|null $order = null): staticThat's a breaking change for extending classes. I tried addressing the deprecations yesterday evening, couldn't finish, and I think I wouldn't expect such a change in a minor release. |
|
Then we don't change this API yet. 🙂 |
|
Sure, but people will still get the deprecation about |
They can use |
|
See doctrine/orm#11315 for a green build in ORM 2.18.x |
And then we ask them to migrate to
Maybe it's best if each package has its own constants or enum, yes 🤔 It would avoid this whole situation entirely. In general, a lot of the pain in Doctrine is caused by exposing types of other packages through inheritance or like this, by using them in our public API. |
|
I got about 200 deprecation notices in a single project because of the deprecation of the I do like the enum by the way, so kudos on having that option! 👍🏻 |
In downstream packages that representation is recommended in places where type hints do not allow using an enum yet, which means we would have to modify the public API of downstream packages to allow it. Let us postpone the deprecation until we figure what exactly needs to be done.
greg0ire
force-pushed
the
postpone-deprecations
branch
from
8fb3eae
to
f614f5d
Compare
|
Just rebasing to know whether Codecov works, but ultimately I will close this, IIRC it's no longer relevant. |
|
Works great. |
In downstream packages that representation is recommended in places where type hints do not allow using an enum yet, which means we would have to modify the public API of downstream packages to allow it.
Let us postpone the deprecation until we figure what exactly needs to be done.
More info on this at doctrine/orm#11313