Failure in HasAttributes trait sfter upgrade to Larvel 10

Using modle->chunk and seeing this error each time it runs:

in_array(): Argument #2 ($haystack) must be of type array, null given

  at Laravel/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.php:2113
    2109▕         // If the attribute is listed as a date, we will convert it to a DateTime
    2110▕         // instance on retrieval, which makes it quite convenient to work with
    2111▕         // date fields without having to create a mutator for each property.
    2112▕         if ($value !== null
  ➜ 2113▕             && \in_array($key, $this->getDates(), false)) {
    2114▕             return $this->asDateTime($value);
    2115▕         }
    2116▕ 
    2117▕         return $value;

If I change "$this->getDates()" to "$this->getDates() ?? []" the failure doesn't happen and the code completes.

Of course, altering Laravel code isn't the answer, so what is my problem?

I removed the protected $dates = [ 'var1', 'varx' ] lines from all models that had $dates defined, as directed in the Upgrade guide. then added those attributes to the $casts list.

Then as part of debugging I reversed that for the model I was using ->chunk() on, but that didn't fix it.

I am pretty certain this as something to do with $dates and $casts, but that'ss just a guess.

Any help would be appriiated.

Snapey

2 years ago

Level 122

i'm a bit puzzled by the workaround since the getDates() function always returns an array

    public function getDates()
    {
        return $this->usesTimestamps() ? [
            $this->getCreatedAtColumn(),
            $this->getUpdatedAtColumn(),
        ] : [];
    }

Just one thought, this might be messed up if you happen to have a model function also called getDates()

emmettculley

2 years ago

Level 2

@Snapey

I just found that our app was using the $dates variable directly and when I removed it to place those attributes in the $casts array as described in the upgrade doc, those model's getDates() method returned and empty object, not an array.

I think somebody in the past was thinking how slick they were for using that variable and overriding the trait. If they were even aware there was a getDates() trait to override. I sure wasn't.

So, exactly as you suggested, our code overrid the getDates() trait. Thank for the reply.

Please or to participate in this conversation.