field.storage.*.*: indexes validation uses "ignore" type therefor is not validated really.

Fun fact is that indexes have a default, like value => [value], but that the shape can be defined in the childs, therefor this is really hard to reallt validate.

From FieldItemInterface:

   *   - indexes: (optional) An array of Schema API index definitions. Only
   *     columns that appear in the 'columns' array are allowed. Those indexes
   *     will be used as default indexes. Field definitions can specify
   *     additional indexes or, at their own risk, modify the default indexes
   *     specified by the field-type module. Some storage engines might not
   *     support indexes.

I think this is overkill really to validate. I would vote to skip trying to validate this.

There are posiiblities to at least check if the schema is part of the columns. But don't really seem much value in that.

Compromise if we keep the ignore can we add a comment why

Hmm, was thinking while writing the comment. It could be validated to be an array. It is optional, but seems to always be an array. The array shape is extrmely flexibly. But an array nevertheless.

bbrala → closed merge request !11675

tried a few different ways to get this to work. I couldn't, its way to diverse imo.

Added the comment.

Can we do this the same way we define plugins? Each one having their own schema?

Not too sure man. Although anything is possible right now looking at contrib (core doesnt really do much here) i see stuff like:

'indexes' => array(
      'target_id' => array(
        0 => 'target_id',
      ),
    ),

      $fields[$field_name]->setIndexes(['value' => ['value']]);

$field_storage->setIndexes([
    'value' => ['value']
  ]);

(url : https://git.drupalcode.org/search?group_id=2&scope=blobs&search=-path%3A...)

And not much more.

I feel like i'm boucing between, it should be possible, and its not worth it every time i read about this. So perhaps i should defer to those who are into this a bit more.

I too am constantly bouncing between the need to validate everything strictly and the looseness that is allowed currently.

Seems pretty straight forward