Skip to content

Conversation

@driesvints
Copy link
Member

@driesvints driesvints commented Jan 4, 2022

Fixes an oversight in #40022.

At the moment when you omit a get cast with the new attribute casting, the attribute call will propagate through the getAttribute method and end up to getRelationValue which will throw an exception that the attribute isn't a relationship instance. This is because the way attribute calls work is to fallback on relationships when they're not available. So the way the checks are done on get/set callables with the new attribute casting isn't entirely correct. We should omit the callable checks and just check if the method that corresponds with the requested attribute is returning an Attribute cast instance. If that's the case we can assume the user wanted to use attribute casting, regardless of a getter/setter being available or not.

A cavaet of this is that this will prevent the call to continue to class casts and the old date casting. I do not know how to solve this and would appreciate any insights you have @taylorotwell.

Fixes #40230

@driesvints driesvints marked this pull request as ready for review January 4, 2022 12:53
@driesvints
Copy link
Member Author

If there's specific scenarios for class casting/date casting in combination with the new attribute casting then we can add those to the existing test case and work until we get all the tests to pass.

@taylorotwell taylorotwell merged commit a6b3868 into 8.x Jan 4, 2022
@taylorotwell taylorotwell deleted the fix-attribute-casting branch January 4, 2022 15:14
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 this pull request may close these issues.

The issue is a new pattern of Attribute Cast

4 participants