Custom cast class overrides the related column

[foremtehan]

Laravel Version

v11.1.1

PHP Version

8.3

Database Driver & Version

sqlite, pgsql, mysql

Description

When you return a new custom class in castable interface's get method, It overrides the related volumn whenever you use the column on the model object

Steps To Reproduce

create a class:

<?php

namespace App\Casts;

class TestCast {}

create a custom castable class and return the above class inside a get method:

<?php

namespace App\Casts;

use Illuminate\Contracts\Database\Eloquent\CastsAttributes;

class AsSetting implements CastsAttributes
{
    public function get($model, $key, $value, $attributes)
    {
        return new TestCast;
    }

    public function set($model, $key, $value, $attributes)
    {
        return [$key => json_encode($value)];
    }
}

Apply this to user's name column (you can add new column to the table doesn't matter)

User.php

protected $casts = [
    'name' => AsSetting::class,
];

I ran these in fresh laravel app:

php artisan db:seed
php artisan tinker

As you can see, when you use ->name, the name column becomes {} for no reason! It doesn't matter if the column type is json, string, etc. it is always overridden by the castable class.

This is really dangerous since this can flush data when you try to save the model after using the attribute.

[OllieCrook]

Hi @foremtehan,

The framework is functioning as expected here. The issue arises from the incompatibility between your get and set methods.

When you access your custom cast using $user->name, an entry is added to the classCastCache array indicating that the class cast has been used. This utilizes your get method to convert the value {"test"} into new TestCast().

However, when you call $user in Tinker or perform an action on the model, such as $user->save() to persist the data into the database, the class cannot be inserted as is; it needs to be serialized.

For normal serialization Laravel uses PHP's __sleep() magic method to prepare the model for serialization. At this point, the $this->mergeAttributesFromCachedCasts() method is called, revealing the issue with your get and set methods.

A part of this method call involves using the custom cast setter to prepare your value. The resulting code essentially does this:

return json_encode(new TestCast());

Since you haven't specified how PHP should serialize your class, perhaps by implementing JsonSerializable, it converts it as best it can, taking class TestCast {} and converting it to {}.

When creating a custom cast, ensure that the output value from your get method can always be passed into your set method and result in the expected output.

I hope this clarifies things. If you have any follow-up questions, I’d be happy to help.

[foremtehan]

I didn't assign a value to the name column, so why would it trigger the set method on the castable class?

Additionally, note that I tested it, and the framework never invoked the set method when using ->name.

[OllieCrook]

It doesn't trigger the set when you access it. But when you access you add an entry to the classCastCache array (see: HasAttributes.php:879

Then later on when it needs to serialize your model it calls the set (see: Model.php:2387 for the main method and HasAttributes.php:1823 for the set call).

Try it yourself. Access it with $user->name then access it again straight after. You'll see it doesn't overwrite. It only overwrites once you serialize it.

[foremtehan]

Overall, this is unwanted behavior. Just imagine using $user->name in your app, and then calling save() somewhere in your codebase afterward. Your data will be lost. I’ll let the maintainers decide whether to close this issue, but I have demonstrated the problem.

[OllieCrook]

You control how the set behaves here so it's up to you to make it work how you want it to work. If you change your get to new TestCast($value), save that value inside the class then on your set retrieve it or implement JsonSerializable you will have no problems.

The comment for the set method even tells you this..

Prepare the given value for storage.

[henzeb]

Overall, this is unwanted behavior. Just imagine using $user->name in your app, and then calling save() somewhere in your codebase afterward. Your data will be lost. I’ll let the maintainer decide whether to close this issue, but I have demonstrated the problem.

Is there a real world example of this? because in the end, get should cast to the object value you want it in, and set should use an object value to convert back to a value that can be stored in the database, which in your case isn't happening at all.