Skip to content

Conversation

@tminich
Copy link
Contributor

@tminich tminich commented Jun 6, 2025

Adds a (currently failing) test for accessing php properties on Laravel models as requested in #2687

@spawnia spawnia added the enhancement A feature or improvement label Jun 6, 2025
Comment on lines +148 to +149
/** @see https://github.com/nuwave/lighthouse/issues/2687 */
public function testPrefersAttributeAccessorNullThatShadowsPhpProperty(): void
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is failing with the current override of the default field resolver, whereas it used to work before.

Comment on lines +182 to +183
/** @see https://github.com/nuwave/lighthouse/issues/1671 */
public function testExpensivePropertyIsOnlyCalledOnce(): void
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we override the default field resolver, we should also consider this issue and fix it too.

Comment on lines +170 to +173
$property = $objectLikeValue->getAttribute($fieldName);
if ($property === null && property_exists($objectLikeValue, $fieldName)) {
$property = $objectLikeValue->{$fieldName};
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we find an implementation that keeps all the tests happy? Or should we bite the bullet and let testPrefersAttributeAccessorNullThatShadowsPhpProperty fail?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I think having a php property and Laravel-access attribute of the same name is an anti-pattern. I'd even argue that php properties should have priority as that is the way php itself does it. Also they are less computationally expensive to check for presence via property_exists.
The only way to check this would involve checking all the Laravel ways you can define an attribute, not sure if that is worth the effort and extra computation for something that should be evaded in the first place.
Also I don't think such a check can be 100% reliable. While I cannot think of a reason someone would do this, the field could refer to a DB column that isn't selected so it does not appear in Model::$attributes.

Something that might be valuable is adding a check in the maintenance artisan commands that check for name collisions and warn the developer. If for some reason they really need to shadow a php property with a model attribute they can create an accessor with a different name and use @rename.

@spawnia
Copy link
Collaborator

spawnia commented Jun 12, 2025

Thank you @tminich for the test and your feedback. I merged a modified version of the tests to ensure the current behavior and opened #2693 to potentially change the default resolver.

@spawnia spawnia closed this Jun 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement A feature or improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants