Undefined array key "type" in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema::castValue()

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

What is "Drupal BO"?

I've just triggered this warning as well:

1) /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php:2567
Undefined array key "type"                                                                                                                                              

2) /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php:2570        
Undefined array key "type" 

but am confused by the OP.
@lendod Did the patch on the Role Delegation module make any difference to your error?

The code that is triggering this error is:

  public static function castValue(array $info, $value) {
    // Preserve legal NULL values.
    if (isset($value) || !empty($info['not null'])) {
      if ($info['type'] === 'int' || $info['type'] === 'serial') {
        return (int) $value;
      }
      elseif ($info['type'] === 'float') {
        return (float) $value;
      }
      return (string) $value;
    }

    return $value;
  }

The $info['type'] in question here is the schema definition of the field as described in the Schema API documentation. Specifically:

'type': The generic datatype: 'char', 'varchar', 'text', 'blob', 'int', 'float', 'numeric', or 'serial'. Most types just map to the according database engine specific data types. Use 'serial' for auto incrementing fields. This will expand to 'INT auto_increment' on MySQL. A special 'varchar_ascii' type is also available for limiting machine name field to US ASCII characters.

Now according to the same documentation you can leave this unset. Which is what was happening in my case (the column has a database type check for 'mysql', so will only install on a MySQL DB, and includes a mysql_type key on the column field definition).

'mysql_type', 'pgsql_type', 'sqlite_type', etc.: If you need to use a record type not included in the officially supported list of types above, you can specify a type for each database backend. In this case, you can leave out the type parameter, but be advised that your schema will fail to load on backends that do not have a type specified. A possible solution can be to use the "text" type as a fallback.

So in the OP I wonder if it wasn't some other field that was causing the issue. I don't see anything obvious in Role Delegation that is adding more than a computed field.

From the above I'd propose to make the MySQL backend fit present behavior (but without a warning) and also fit the documentation a isset should be added to the above code, making it.

  public static function castValue(array $info, $value) {
    // Preserve legal NULL values.
    if (isset($value) || !empty($info['not null'])) {
      if (isset($info['type'])) {
        if ($info['type'] === 'int' || $info['type'] === 'serial') {
          return (int) $value;
        }
        elseif ($info['type'] === 'float') {
          return (float) $value;
        }
      }
      return (string) $value;
    }

    return $value;
  }

Change like this usually means an isset() is masking a larger issue shouldn't we address that so it's always set. May require test coverage.

Change like this usually means an isset() is masking a larger issue shouldn't we address that so it's always set.

It's not going to be core code that is calling it with the key not set, because the reason for it not to be set is if you have a column that is only for a specific database backend, and has no fallback. The documented configuration for columns with no fallback is not to set one. So I'm not quite sure how you can make it always set? Changing the documentation (which I guess is an API??) to require a NULL when there isn't one at a guess?

So if core isn’t causing this wouldn’t it be a bug in the contrib or custom module that is causing it?

So if core isn’t causing this wouldn’t it be a bug in the contrib or custom module that is causing it?

As they are following the Schema API documentation. I don't think so. It would require a change to the requirements as documented for API (as quoted above) where it states that you can configure it with no fallback key set.

Can we clean up the summary some and then put back into review for additional eyes. Not sure the way forward for this one.

Since there's been no additional follow up maybe next step would be to add a test case that demonstrates the issue.

While there has not been any reply I've been trying out:

> Check to see if requiring the type key with a NULL or (string) '' value works with the rest of the implementation and updating the API to make it required even when the type is database specific and there is no fallback,

in my code

```
$schema['columns']['start_utc'] = [
'description' => 'Start DateTime.',
'type' => NULL,
'mysql_type' => 'datetime',
];
```

and so far that's working.

So the answer is maybe changing the API specification/documentation to reflect reality.

That I cannot answer unfortunately, sorry! But lets see if the sub-maintainer would know.