Problem/Motivation

I've the following definition,

     $fields['type'] = BaseFieldDefinition::create('list_string')
      ->setLabel(t('Type'))
      ->setDescription(t('The type of receiver'))
      ->setSettings([
        'max_length' => 16,
        'allowed_values' => [
          'email' => 'email',
          'mobile' => 'mobile',
        ],
      ]);

    $fields['receiver'] = BaseFieldDefinition::create('string')
      ->setLabel(t('Receiver'))
      ->setDescription(t('The email/phone to receive the OTP.'))
      ->setSettings([
        'max_length' => 192,
        'text_processing' => 0,
      ]);

    $fields['is_verified'] = BaseFieldDefinition::create('list_string')
      ->setLabel(t('Is Verified'))
      ->setDescription(t('Whether the OTP been verified or not'))
      ->setDefaultValue('pending')
      ->setSettings([
        'max_length' => 16,
        'allowed_values' => [
          'pending' => 'pending',
          'yes' => 'yes',
          'no' => 'no'
        ],
      ]);

Both BaseFieldDefinition::create('list_string') and BaseFieldDefinition::create('string') under the hood are using varchar(255) by default. While 'string' respects the 'max_length', the 'list_string' seems not taking that into account.

I'm hitting the InnoDB table limit while trying the index some columns. I guess the indexing would be successful if I could set optimal length for them.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

sivaji_ganesh_jojodae’s picture

Issue summary: View changes

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

kristiaanvandeneynde’s picture

I was just bitten by this too, trying to add an index on a list_string field (among other fields) and noticing nothing out of the ordinary. Only when looking deeper did I notice Drupal had reduced the field's index length to 191, essentially making the index do nothing. Even worse, because the index now exists and cannot really help, the overall outcome is slower than if I had not tried to set an index at all.

Manually changing the field's database column size to something smaller fixes things. But I agree that this should be read from max_length instead of hard-coded to 255.

Edit: Since we now require MySQL 5.7+ for Drupal, I wonder how relevant Schema::getNormalizedIndexes() still is.

kristiaanvandeneynde’s picture

Did some digging and found this CR: https://www.drupal.org/node/2510940

That indicates you can use max_length and is_ascii to manipulate the schema of a StringItem, which is true. Seems like ListStringItem was overlooked?

kristiaanvandeneynde’s picture

Title: Not possible to set MySQL column max_length for custom entity of type list_string » Missing settings max_length or is_ascii for ListStringItem.
Issue tags: -custom entity
kristiaanvandeneynde’s picture

Opened #3620372: MySQL Schema::getNormalizedIndexes() still assumes old, unsupported databases for the thing Drupal does to indexes, and then maybe this issue can be repurposed for allowing ListStringItem to also have the settings that can manipulate the schema.