32 character field name length limitation

I have wondered about this limit. I can no reason why it would be capped at 32 chars, and in a large application it is really difficult to maintain sensible naming conventions with such a limit in place.

Remember of course that 6 chars get taken for 'field_' as well!

Is this going to be changed in D7?

Thanks for the patch, additionally you'd probably need to alter content_group_fields table to make fields varchar(64) instead of varchar(32)

The D7 version has the same limit, so changing it in D6 would make it impossible to upgrade to D7. The field name is used in many ways and there are some places where a limit is needed. I don't ATM remember all the reasons why it had to be 32, but I assure you that has been hashed out in the past.

I agree that this isn't a bug but having 32 bytes is rather difficult if you have hundreds of fields and need meaningful names for them. Isn't there a chance to review it and probably change for both D6 & D7?

There is nothing else I can say, there is no point in re-opening this. This has always been built into the module, I don't remember what all the reasons were and have no time to try to find all the issues to point you to. It won't get changed in D6 or D7 so there is no point in letting people create fields that will break. If you want to patch things and see what breaks for you, you are welcome to do so in your own installation, but we can't add this into the code we maintain without confirming it will not break anything anywhere, and the subject has come up before so I know something somewhere *will* break.

For anyone else hitting this seemingly arbitrary limitation, there is an explanation here that I discovered: http://drupal.org/node/198420#comment-652923 .
I hit the same limitation creating a CTools content-type plugin for the Panels module today.

Karen's explanation was that: "We already have problems with the size of CCK queries with all the long field and table names". However max query size is configurable on the DB server side and I believe with time there will be more demand to increase it because more large websites will switch to Drupal. As an example: I work on a growing website having 500+ CCK fields at the moment and it would be a real pain to have a separate translation spreadsheet for all the field names.

See also #1191434: Standardize entity type is a maximum of 32 characters (not 64 or 128), where chx says:

each char takes three bytes in an index and you only have 1000 of those.

and Dave Reid says:

The problem is that with a longer value, entity_type is *very* commonly used in primary keys and indexes (which for cross-db compatability must have <1000 bytes). If entity_type = 128, then we are already at 384 bytes or 38% of the available key length. Add a field like bundle (128 chars / 384 bytes) or field_name (32 / 96 bytes), and it fills up fast. I think it makes sense to keep entity types fairly short (and the same length as field names). Once we have a length standardized, we can increase it as needed in the future.