-
Notifications
You must be signed in to change notification settings - Fork 11.2k
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
Inconsistent accessor attribute name conversion #54570
Comments
Because it actually gets appended, I'd expect it to work when you do ->toArray(); it looks like its down to The key you enter into the append method won't match because it does Str::snake(foo1Bar) internally which gives Will see if I can PR a fix :) |
@Propaganistas @jackbayliss the issue was reolved in below PR thanks! |
@pandiselvamm Nice, beat me to it! 👍🏻 |
Thank you for reporting this issue! As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub. If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team. Thank you! |
Laravel Version
11.42.0
PHP Version
8.4.3
Database Driver & Version
No response
Description
Define a custom attribute with a convoluted name using the
Attribute
syntax:Example:
Accessing a custom attribute is internally done by a snake-to-camel case conversion. So this means both
foo1_bar
andfoo_1_bar
will yield the expected value.However, some features in Eloquent do the inverse by calling upon the attribute cache (
$getAttributeMutatorCache
): a camel-to-snake case conversion. This means thatfoo1Bar
now only translates tofoo1_bar
, and not anymore tofoo_1_bar
even though its value would get returned when retrieving it.On the contrary, when resorting back to the good old
getFoo1BarAttribute()
everything works as expected for bothfoo1_bar
andfoo_1_bar
.So, because of internal two-way case conversions to support the newer attribute syntax some unexpected and disfunctional ambiguity gets introduced.
I think both syntaxes (
Attribute
vsgetXXXAttribute()
) should behave equally. But I'm not quite sure how to proceed with this. Shouldfoo_1_bar
get blocked for access to prevent this kind of expectations further down the line? Or should it also resolve properly when doing the camel-to-snake conversion? Or...?Steps To Reproduce
The text was updated successfully, but these errors were encountered: