Inconsistant Cast Behavior for Eloquent

[ragingdave]

When using the fill method, any $casts are ignored. Ex.

'valid' => 'boolean'

Works:
$object->valid = 'something'; // Will convert to a 1 for database storage

Doesn't work:
$arr = ['valid' => 'something'];
$object->fill($arr); // will stay as 'something'

Temporary Fix is just to make a setValidAttribute($valid) mutator but I would think that in order to have consistent behavior across the board, $casts should be respected anyway that attributes can be set.

[GrahamCampbell]

Looks like a bug to me.

[ibrasho]

I'm pretty sure that $object->valid = 'somthing'; will not cast the value unless you try to access it.

Try to dd() or dump() the object after you do that to see the actual value.

So this is expected behaviour.

[ibrasho]

Both Model::fill() and Model::__set() use Model::setAttribute() to set the attribute value.

[ragingdave]

Hmm... I somehow am not able to replicate this again, maybe I was doing something funky.
Either way to add on/change this bug a bit.
The documentation says the following:
"Otherwise, you will have to define a mutator for each of the attributes, which can be time consuming."
which is what led me to believe that the cast would occur in setting and getting.

On top of that there is some implicit casting going on if you have a json castable item. as seen in Model::isJsonCastable() which is called from Model::setAttribute(). I would say there should either be cast checking for any column set as castable or none as this was actually a bit confusing.

[FractalizeR]

Model::setAttribute() doesn't make any casts in 5.1 source. Only Model::getAttribute() does. Is this intended?

[ragingdave]

...It actually does....
https://github.com/laravel/framework/blob/5.1/src/Illuminate/Database/Eloquent/Model.php#L2766
https://github.com/laravel/framework/blob/5.1/src/Illuminate/Database/Eloquent/Model.php#L2770
both of those reference implicit casting for specific cases which is where this ticket came from.

[FractalizeR]

@ragingdave But that relates only for dates and json casts. Not $casts attrubute related fields

[ragingdave]

Again actually it does....
https://github.com/laravel/framework/blob/5.1/src/Illuminate/Database/Eloquent/Model.php#L2685
leads to
https://github.com/laravel/framework/blob/5.1/src/Illuminate/Database/Eloquent/Model.php#L2676
So it in fact does deal with $casts. It doesn't care specifically about casting it using castAttribute, but it does cast an array/json/object/collection to a string using json_encode.

[rkgrep]

I guess it was done for a reason - according to castAttribute method phpDoc casting is made to a native PHP type. So it is made to avoid incorrect handling of values from different database types (e. g. MySQL uses integer to implement booleans while PostgreSQL has native boolean type).

You should control types written to database from you code while Eloquent prevents your code from getting unexpected types.

This differs from JSON - which must always be encoded to string before passing to PDO.

[ragingdave]

Wouldn't that specific of casting happen in the specific connection?
I assume eloquent shouldn't care about the underlying PDO that is being used, so in that train of thought any casting to handle that type of requirement at a storage engine level should not be a Model but instead be in the Connection layer perhaps when the statements get prepared and whatnot to convert specific types to database friendly ones?

[rkgrep]

@ragingdave Ideally - it is.
But actually this is possible only by analyzing schema configuration (because TINYINT(1) in MySQL is not always boolean).
But migrations are not present in all projects - e. g. I don't duplicate migrations on projects using the same DB. And also this would be very slow - as it is needed to execute all migrations one by one to get final schema configuration.

So implementing this in a Model is much more handy - you always know which fields you will get from DB and which casting type you should use. And the same vice versa - you always know what kind of data you should store in a Model field.

I think if casting will be enabled on attribute setting, then peoples will tend to avoid proper validation (mistakely believing the Model will properly cast values), thus causing unexpected data written to database.

[wlepinski]

I had a similiar problem today regarding the casting implementation.
I was using the 5.0.31 version with a custom Pivot class. On this class I had:

protected $casts = [
  'details' => 'array'
]

I tried to update to v5.0.33 and I noticed that when I asked for the value of details using my pivot I was receiving a string instead of an array. I did a diff between v5.0.31 and v5.0.33 and found 2 method calls on Pivot.php class.

$this->forceFill($attributes);
$this->syncOriginal();

The forceFill method seems to be the problem in my case, it calls the setAttribute method that checks the attribute using isJsonCastable and encode the value twice. So for a object stored as { c1: "on" } as string becomes serialised version of the string "{ c1: "on" }" which cannot be decoded using json_decode.

For me, as a workaround I had to implement the method getDetailsAttribute on the Pivot and remove the property from $casts array to avoid the double encoding problem.

I'm still figuring out a more smart solution.