Testbot futzing (please ignore this issue)

now trying the last patch which worked.

slowly adding more to the working patch: 1) rdf.install and 2) rdf.crud.inc
let's see what the bot says

rdf.install seems to be the culprit

looks like the bot is not digesting the schema. I must be missing something.

looks like 'primary key' => array('type', 'bundle'), is the culprit...

trying with indexes on the primary key

some more testing.

the problem comes from the primary key. can't believe this is not causing any trouble on my 2 localhost (Mac OS and ubuntu) and on none of the other developers localhost.

ok, so this boils to the following:
- the test bot servers do not like a primary key of type PRIMARY KEY ( varchar(255), varchar(128) ) and will return the error: Failed to install HEAD.

  $schema['rdf_mapping'] = array(
    'description' => 'Stores custom RDF mappings for user defined content types or overriden module-defined mappings',
    'fields' => array(
      'type' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'description' => 'The name of the entity type a mapping applies to (node, user, comment, etc.).',
      ),
      'bundle' => array(
        'type' => 'varchar',
        'length' => 128,
        'not null' => TRUE,
        'description' => 'The name of the bundle a mapping applies to.',
      ),
      [...]
    ),
    'primary key' => array('type', 'bundle'),
  );

- the install will work if the length of type is changed to 128 or 64.
- the patch 24 shows that defining a unique key of array('type', 'bundle') with type=>varchar(255) and bundle=>varchar(128) will lead to the same failure on install, so unique keys seem to be governed by the same rule as the primary key.

I'm attaching the latest RDF patch with the primary key length fix to see if it installs ok.

note 1: all these worked perfectly on all the development setups, so the testing servers must have a restricted mysql configuration. I'd be interested to know what settings in mysql affect this, so that I could tune my local mysql the same way. That have save me so much time...

note 2: some testing servers might be running pgsql? I didn't try this patch on pgsql and I'm not sure how pgsql would have reacted.

I found the reason why this was working on my localhost and not on the testing servers. The answer is on the Restrictions on InnoDB Tables for MySQL 5.1 which is the version of MySQL I use on both localhosts:

The InnoDB internal maximum key length is 3500 bytes, but MySQL itself restricts this to 3072 bytes.

Since we're using UTF8, it means the maximum key length one can create is 1024 (3 bytes per char in UTF8). This was confirmed by the error PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 3072 bytes when creating a key greater than 1024 char.

Drupal 7 requires MySQL 5.0 which implies:

The internal maximum key length is 3500 bytes, but MySQL itself restricts this to 3072 bytes. (1024 bytes for non-64-bit builds before MySQL 5.0.17, and for all builds before 5.0.15.)

Our original schema contained a primary key on ('type', 'bundle') which are respectively varchar(255), varchar(128), summing up to 383 char and exceeding 1024 bytes when multiplied by 3.

I can only conclude the testing servers are running MySQL 5.0.15 or an earlier version.

I've switched the type varchar length to 128 for now until we decide what to do about it.

this should fix the exceptions.

oops, wrong patch.

all green and all the RDF tests are executed. great! thank you test bot for your patience...

reopening this temporary issue to test if the new bot can better report this kind of problem. see #600490: Switch entity type column from varchar(255) to varchar(128) for the active issue.

Not so much difference between "Failed to install HEAD" and "Detect a Drupal installation failure"...

reopening to test this patch which currently fails on that main issue. trying variant of the patch here.