Increase maximum length of 32 characters for field machine names to a higher limit

Created on 14 July 2021, about 4 years ago
Updated 20 September 2024, 10 months ago

Problem/Motivation

Currently the maximum length of machine names is limited to 32 characters.

See this change record: Entity type and bundle machine names have a maximum length of 32 characters β†’

It is a limit that is rather short and easy to hit when creating new content-entities and fields.
Cropped machine names show up in config-exports, so there are real artefacts of the 32 character limit in many projects.

I don't know the exact reason for 32, but I guess 8 or 16 was too short and higher numbers felt unneeded and possible lead to slower database performance.
I can't exactly tell if there are performance implications, but an increased size to 64, 128 or even 512 characters would be better IMO.

Answer Berdir https://www.drupal.org/project/drupal/issues/3223605#comment-14164276 ✨ Increase maximum length of 32 characters for field machine names to a higher limit Active :

Not going to close the issue, but that's not really possible.

We didn't pick that number just for fun. field config entity IDs consist of entity type + bundle + field name. The max id length of a config entity is 166 ( \Drupal\Core\Config\Entity\ConfigEntityStorage::MAX_ID_LENGTH). entity types and bundles can each be 32. so 32 each gives you ~100 for fields. and bundles (node types) can't be longer than 32.

Field names then again are referenced in several tables, for example comment.

I strongly recommend to keep them as short as possible. Longer field names need to be hashed, which IMHO complicates the database structure. It's not really a performance issue, more a DX issue if you ever need to do some queries and things there to investigate things. Much easier to find the right tables then.

✨ Feature request
Status

Active

Version

11.0 πŸ”₯

Component
Configuration entityΒ  β†’

Last updated 4 days ago

Created by

πŸ‡³πŸ‡±Netherlands ndf Amsterdam

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΉπŸ‡·Turkey emircan erkul Turkey

    Can't we get some from ConfigEntityStorage::MAX_ID_LENGTH and use for machine names? 32+16=48 would be sweet spot IMO and ConfigEntityStorage::MAX_ID_LENGTH become 166-16=150

  • πŸ‡ΊπŸ‡ΈUnited States seanr

    I got curious as to the underlying reason for this limit and of course found it in the API docs - seems to be a file system limit:

    https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Config%21...

    Most file systems limit a file name's length to 255 characters, so ConfigBase::MAX_NAME_LENGTH restricts the full configuration object name to 250 characters (leaving 5 for the file extension). The config prefix is limited by ConfigEntityType::PREFIX_LENGTH to 83 characters, so this leaves 166 remaining characters for the configuration entity ID, with 1 additional character needed for the joining dot.

    Not going to change the issue status myself, but perhaps this should be won't fix?

  • πŸ‡¦πŸ‡ΉAustria maxilein

    It is still too short to reflect a naming convention that makes sense in a broader context on a complex site...
    Not even windows is fixed to 255 limt anylonger...
    And what does a table field size have to do with the filesystem anyway?

  • πŸ‡ΊπŸ‡ΈUnited States seanr

    @maxilein - the reason has to do with config being exported to files, for example: simple_sitemap_engines.bundle_settings.taxonomy_term.leadership_filter.yml

  • πŸ‡¦πŸ‡ΉAustria maxilein

    Most modern file systems have longer naming possibilities.

    And why not use standardized abbreviations for common Drupal constructs: like bundle_settings.taxonomy_term could as well be bs.tt then you would have much more room for an intuitive naming convention that reflects the individual aspects of a site.

  • πŸ‡ΊπŸ‡ΈUnited States seanr

    I strongly oppose abbreviations like that, especially ones that short. You'd obviously end up with namespace collisions very easily, but even beyond that, it is extremely helpful to be able to know exactly what you're looking at in config exports. That sort of thing would completely obfuscate the system. And unnecessary obfuscation, just like ending a sentence with a preposition, is an offence up with which I shall not put! πŸ˜€πŸ˜€πŸ˜€

Production build 0.71.5 2024