-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add Fully-Qualified class name in UnrecognizedField exception #10342
Add Fully-Qualified class name in UnrecognizedField exception #10342
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea, I think I remember losing time over this a few years ago.
cd6f352
to
47b3814
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can see were these the only occurrences of UnrecognizedField::byName()
and this method is now unused. Exceptions' named constructors are for internal usage, but can be used elsewhere in userland. Should it be removed now or set as deprecated first?
I'm OK with it being removed now. |
I thought it would be a BC to remove it, some users may use this method. Maybe we should deprecate it instead ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I'm nit-picking too much here, but if the exception message is that important to you, I believe we should have a test that makes sure the exception message is as you expect it to be.
This PR is filed as a bugfix, so I'd really vote against removing any methods. Yes, I believe we should deprecate the method, but we cannot introduce deprecations in a bugfix release either. So let's do that in a follow-up on 2.15.x. |
Regarding what is a BC and what is not : https://xkcd.com/1172/ I always fear I'm going to be too strict, only to find my fellow maintainers think otherwise. The BC is small, but this isn't just any library, so let's avoid unnecessary risks. |
eddd5d8
to
2de8a96
Compare
Done :)
I added a deprecation notice with a link to the new method. |
tests/Doctrine/Tests/ORM/Persisters/Exception/UnrecognizedFieldTest.php
Outdated
Show resolved
Hide resolved
2de8a96
to
afeec59
Compare
afeec59
to
c52faf9
Compare
* 2.14.x: Shorter deprecation message (doctrine#10357) Add Fully-Qualified class name in UnrecognizedField exception to ease debugging (doctrine#10342) Include parameter types in hydration cache key generation (doctrine#10355)
* 2.15.x: Shorter deprecation message (doctrine#10357) Add Fully-Qualified class name in UnrecognizedField exception to ease debugging (doctrine#10342) Include parameter types in hydration cache key generation (doctrine#10355) Allow doctrine/instantiator 2 (doctrine#10351)
Currently if we use a field that is not properly registered in our mapping, we end up with the following exception from the
BasicEntityPersister
:As with a complete stack trace we may be able to dig enough to find the right mapping, it can take more time to find the concerned entity in a context with less informations, such as logs.
This PR adds the entity FQCN to the exception message to ease debugging in such cases, using the class metadata available in
BasicEntityPersister::class
property. We end up with:As I didn't encountered any tests for the existing
UnrecognizedException
class behavior, I didn't add some but I can if needed.