Details
-
Type:
Improvement
-
Status: Won't Do
-
Priority:
Major
-
Resolution: Won't Do
-
Affects Version/s: 4.4.16, 4.5.5, 4.6.5
-
Fix Version/s: Unscheduled
-
Component/s: Core CiviCRM
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
When a user adds more than 64 searchable custom fields to a given custom data set, CiviCRM will attempt to create a MySQL index on the table for each field. But MySQL INNODB can only put a max of 64 indexes on a given table. ( http://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html)
The result of the bug is that CiviCRM thinks the custom field exists (as there is a record in the table "civicrm_custom_field" ) BUT there is no field created in the table "civicrm_value_something" This situation causes a variety of errors when users attempt to use, (or even delete the field).
Related question: Why is it necessary to to create a MySQL index just to make a custom field searchable on the CiviCRM advanced search and CiviCRM report templates? Seems like in many situations, having an index is not really needed. (Or maybe this could be a different setting than "is this field searchable". The new settings would only be available to people with permission, which would NOT be the user who is organizing an event registration)