Fix casting issue

[hans-thomas]

Hello friends,
If you had a look at this repository, you would find that one of the most reported issues is failing to cast attributes on creating/saving data on the database. There are some issues that have been opened since 2018: #1580, #2199, #2257, #2393, #2651.
I applied #2257 PR and specifically wrote tests for each data type that might had an impact.
In this PR, I had to override asDecimal and fromJson methods from the Illuminate\Database\Eloquent\Concerns\HasAttributes trait.

[GromNaN]

Thank you for reviewing these issues and proposing a fix. I have a few remarks, and I still need to test your branch. But overall it looks great!
Big up for all the tests.

[GromNaN]

Do you think there is some error cases that could be added? Like data that can’t be casted.

[GromNaN]

Is there a case with decimal without the prevision part?

[hans-thomas]

As mentioned in the #2146 issue, an error will be thrown.

[hans-thomas]

Do you think there is some error cases that could be added? Like data that can’t be casted.

I tried my best to cover any possible failure in casting values and nothing new came to my mind.

[GromNaN]

LGTM.

[GromNaN]

Thank you @hans-thomas. I merged into 4.1 because the behavior changes and some users may rely on the current behavior.

[apeisa]

Thanks @hans-thomas for this! It works, but not in all cases. When using date casts, you can also define the format in the string format, like this (docs):

   protected $casts = [
        'mydate' => 'datetime:j.n.Y H:i',
    ];

When using cast like that, it doesn't work. Without formatting set, it does work as expected:

   protected $casts = [
        'mydate' => 'datetime',
    ];

[hans-thomas]

Hello @apeisa, I had some tests on datetime cast with custom formatting, It's not from my changes because obviously, I did not change a thing on date casting. Please open a new issue and I will try to fix that. Thank you for your feedback.

[apeisa]

Sure thing, here you are #2655

[jmikola]

I merged into 4.1 because the behavior changes and some users may rely on the current behavior.

@GromNaN: Did you create a PHPORM issue to track this? If not, is it worth doing so for generating release notes down the line, or is that not necessary for this project?

[rbruhn]

Coming back to this after some time away.
Am I to assume this fixes "set" when saving data? For example:

// Inside Subject Model
protected $casts = [
    'project_id' => 'integer'
];

// Script
$subject = new Subject();
$subject->project_id = "1000";
$subject->save();

Because it doesn't and I'm on v4.3.0.
When viewing the record in Mongo, the project_id is Type = string, not integer.