fusion_apply_skins table - "Specified key was too long; max key length is 1000 bytes"

Patch worked OK on my localhost site (mySQL 5.1.44). Ran update.php with no issues. When that was completed all of my skin settings were gone, but clearing site cache restored them.

When I tried to import the database from my localhost site (mySQL 5.1.44) to my webserver (mySQL 5.1.41) I still receive the same error:

CREATE TABLE `fusion_apply_skins` ( `sid` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The primary identifier for a skin configuration.', `theme` varchar(128) NOT NULL DEFAULT '' COMMENT 'The theme this configuration applies to.', `module` varchar(128) NOT NULL DEFAULT '' COMMENT 'The module this configuration applies to.', `element` varchar(128) NOT NULL DEFAULT '' COMMENT 'The element this configuration applies to.', `skin` varchar(255) NOT NULL DEFAULT '' COMMENT 'The skin that has been applied.', `options` longtext NOT NULL COMMENT 'A serialized array containing the skin options that have been applied.', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'Boolean indicating whether or not this item is enabled.', PRIMARY KEY (`sid`), UNIQUE KEY `theme_module_element_skin` (`theme`(40),`module`(40),`element`(40),`skin`(40)), KEY `theme` (`theme`), KEY `module` (`theme`,`module`), KEY `element` (`theme`,`module`,`element`), KEY `skin` (`skin`) ) ENGINE=In[...]

MySQL said: Documentation
#1071 - Specified key was too long; max key length is 1000 bytes 

The CREATE TABLE for fusion_apply_skins of my database dump (from localhost site after the patch) was:

CREATE TABLE `fusion_apply_skins` (   
  `sid` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The primary identifier for a skin configuration.',   
  `theme` varchar(128) NOT NULL DEFAULT '' COMMENT 'The theme this configuration applies to.',   `module` varchar(128) NOT NULL DEFAULT '' COMMENT 'The module this configuration applies to.',   
  `element` varchar(128) NOT NULL DEFAULT '' COMMENT 'The element this configuration applies to.',   
  `skin` varchar(255) NOT NULL DEFAULT '' COMMENT 'The skin that has been applied.',   
  `options` longtext NOT NULL COMMENT 'A serialized array containing the skin options that have been applied.',   
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'Boolean indicating whether or not this item is enabled.',   
  PRIMARY KEY (`sid`),   
  UNIQUE KEY `theme_module_element_skin` (`theme`(40),`module`(40),`element`(40),`skin`(40)),   
  KEY `theme` (`theme`),   
  KEY `module` (`theme`,`module`),   
  KEY `element` (`theme`,`module`,`element`),   
  KEY `skin` (`skin`) ) 
ENGINE=InnoDB AUTO_INCREMENT=178 DEFAULT CHARSET=utf8 COMMENT='Stores Fusion Apply data.' AUTO_INCREMENT=178;

I also compared the Skin export code from my localhost site pre-patch and post-patch, and the export code was the same. So perhaps, if it does not already, the update script should edit all entries in the table to shorten the keys?

@authentitech - can you let us know what mySQL version you are running?

Thanks!

This is on my database that was experiencing the error messages (mySQL version 5.1.41)

mysql> show variables like '%char%' ;
+--------------------------+---------------------------------------------+
| Variable_name            | Value                                       |
+--------------------------+---------------------------------------------+
| character_set_client     | utf8                                        |
| character_set_connection | utf8                                        |
| character_set_database   | utf8                                        |
| character_set_filesystem | binary                                      |
| character_set_results    | utf8                                        |
| character_set_server     | utf8                                        |
| character_set_system     | utf8                                        |
| character_sets_dir       | /opt/mysql/5.1.41-gm2/share/mysql/charsets/ |
+--------------------------+---------------------------------------------+
8 rows in set (0.00 sec)

mysql> describe fusion_apply_skins;
+---------+------------------+------+-----+---------+----------------+
| Field   | Type             | Null | Key | Default | Extra          |
+---------+------------------+------+-----+---------+----------------+
| sid     | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| theme   | varchar(128)     | NO   | MUL |         |                |
| module  | varchar(128)     | NO   |     |         |                |
| element | varchar(128)     | NO   | MUL |         |                |
| skin    | varchar(255)     | NO   | MUL |         |                |
| options | longtext         | NO   |     | NULL    |                |
| status  | tinyint(4)       | NO   |     | 0       |                |
+---------+------------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

So, yeah, it looks like the character encoding is what was causing you to not see the problem. I will test this patch #6 and respond shortly.

patched my localhost site and ran update.php (mySQL 5.1.44). Then, did a db dump and imported onto my server (mySQL 5.1.41) with no problems. After clearing cache all my Skins re-appeared as expected.

The next stable release of Fusion Accelerator is awaiting thorough testing of our responsive features. If you would like to help move along the process of rolling a new stable release, we would love to have your feedback on the responsive features. Until we are ready to release those features, however, this issue will have to be resolved via the patch in this thread or by using the latest dev release.

This fix is included in Fusion Accelerator 7.x-2.0-beta1