When running update.php im getting this
the site is currently being upgraded, though everything else works without errors

The following updates returned messages

draggableviews module

Update #7001
Failed: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes: ALTER TABLE {draggableviews_structure} CHANGE `view_name` `view_name` VARCHAR(128) NOT NULL DEFAULT '' COMMENT 'Makes the order unique for each view.'; Array ( ) in db_change_field() (line 3017 of /mysite/includes/database/database.inc).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

P2790’s picture

I can confirm I have the same issue

ngreenup’s picture

I am also receiving this error

Paulraj Augustin’s picture

I too got the same error.... Any solution??? Please help

sajt’s picture

I think there is no option for upgrade from drupal 6 to drupal 7. Is this true?

amcc’s picture

nothings been upgraded on this module for a long time - its not a particularly complicated module so if you'd like to upgrade it shouldnt be too hard

iStryker’s picture

Status: Active » Postponed (maintainer needs more info)

There is currently no option upgrade option from Drupal 6 to Drupal 7.

Can you confirm you are gettting this error from upgrade 7.x-1.x to 7.x-2.0.

iStryker’s picture

Status: Postponed (maintainer needs more info) » Active

Did some more investigation. This is a problem because you are using MYISAM storage engine tables. This has a limit of 100 bytes for a index.

There is an index 'view' => array('view_name', 'view_display', 'args', 'entity_id'), View Name, View Display and Args are all varchar.

MYISAM is the default storage engine for old verisions of MySQL

Rob C’s picture

#2414769: Upgrade fails on database upgrade thats close to this issue, but for innodb. Might help to really fix this. (hope it helps a bit). Updating a table to InnoDB indeed works, but that's not always possible, so this needs to fixed in code.

iStryker’s picture

Yes #2414769 has the same problem.

Yes we should fix this. We can use prefix indexes. The question is what length. If it was only 1 varchar in the index, then 50 would work. Because there is 3 varchar, this does not work.

iStryker’s picture

Title: update php PDO Exception » update php PDO Exception for MYISAM database tables
Status: Active » Needs review
FileSize
6.71 KB

I think I made a mistake in #9. It is 55.5 character per column, not per index.

Attached is patch. This should work for 7.x-1.x to 7.x-2.x, 7.x-2.0 to 7.x-2.x and not break current 7.x-2.x-dev.

iStryker’s picture

FileSize
1.96 KB

Bad patch in #10, Try this

Rob C’s picture

Functionally the patch in #11 seems to work great! Added it to a huge site's test env and reran the update. No problems at all. Will retest some more on other sites asap.

iStryker’s picture

Ok looks like this will get commit in 7.x-2.2. Adding Parent

lsolesen’s picture

Status: Needs review » Reviewed & tested by the community

After applying the patch in #11, I was able to upgrade, so marking as RTBC.

Referenced issue #2446139: Executing draggableviews_update_7203 giving Specified key was too long; max key length is 1000 bytes

Rob C’s picture

Tested with 3 more sites, still RTBC.

  • iStryker committed 8734295 on 7.x-2.x
    Issue #2210473 by iStryker, amcc: update php PDO Exception for MYISAM...
iStryker’s picture

Status: Reviewed & tested by the community » Fixed

Committed. @Isolesen double-checking....you said MYISAM was part of the Aegir/BOA stack? I am a little surprised by that, as it is a well built supported stack.

lsolesen’s picture

MYISAM is optional on BOA / Aegir. It takes up much less space. There is an explanation here for the BOA stack: https://omega8.cc/faq

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

kolafson’s picture

I just ran into this exact problem (with a BOA site that was getting too big due to records being constantly added/removed from a couple tables). Thanks for committing the fix iStriker!

jmart’s picture

This problem is still in 7.21 code. I still had to apply the patch in #11

iStryker’s picture

@jmart If you are running 7.x-2.1 you will need to to apply patch #11. If you are running 7.x-2.x-dev you do not have to, as it is already fixed on the dev branch. Once 7.x-2.2 comes out you, it will already have #11 in it.