Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I was trying to install this module, but after I enabled it I got an error and a couple of tables were not created.
I noticed that on the mysql server I have to use there is a limit of 1000 bytes on keys.
The table ultimate_cron_signal has the primary key composed by columns job_name and signal_name, both varchar(255).
The charset is utf8, so these 2 columns may have 3 bytes per characters, so the key hits the limit.
You should either
- change the size of these columns making the sum of their length no more than 333 characters
- change the charset of the columns to ascii or iso8859_15
- use an auto_increment primary key (but you still can't create an unique key on the two columns)
- create a table for the values of job_name and/or signal_name, associating a numeric id to each string, and use the ids instead of the strings in the table ultimate_cron_signal
Comment | File | Size | Author |
---|---|---|---|
#6 | db_import_abort_via_ultimate_cron_signal.png | 67.29 KB | frederickjh |
Comments
Comment #2
fabio84For a quick and dirty workaround, I have reduced the length of column signal_name to 78 characters in file ultimate_cron.install and I was able to install the module without errors.
Is it safe to have this column at 78 characters or do you think I may easily have longer values and crash something? Do you suggest better lengths for the two columns or other (quick) solutions?
Comment #4
Proteo CreditAttribution: Proteo as a volunteer commentedIt looks like the change introduced in fc3cbbe is not compatible with PostgreSQL. When applying database updates from the latest 7.x-2.0rc2 it throws the following errors:
And in the update.php page:
Since the update process halts after deleting the
ultimate_cron_log
index, I had to manually modify the lines of the update, and run it again to recreate it:Let me know if I can do further testing for you.
Comment #5
mestaton CreditAttribution: mestaton as a volunteer commentedThis is an issue for new installs (Drupal version 7.43, enable via drush, Postgresql 9.3.12) as well:
Comment #6
frederickjhI just ran into this when trying to import a new dump of my database into my test environment. It total hosed the sql import with:
A fix for this is still needed.
Comment #7
morbiD CreditAttribution: morbiD commentedCorrect me if I'm wrong, but I'm not sure why this 1000B thing is a bug that needs fixing in the module...
The MySQL documentation states:
Therefore, given that Drupal defaults to using InnoDB and InnoDB defaults to a 16KB page size, isn't this a server configuration issue and down to a server admin to resolve?
Furthermore, commit fc3cbbe in #3 added prefix lengths to various indexes and keys which as far as I can see, weren't causing any problems the way they were before. That change now makes them useless for sorting/grouping queries (which ignore indexes with prefix lengths) and is partly contributing to a separate issue over in #2379871-34: White Screen of Death on admin/config.
Comment #8
gielfeldt CreditAttribution: gielfeldt commentedEDIT: Wrong ticket ... 2 sec...
Comment #9
gielfeldt CreditAttribution: gielfeldt commentedI think it could be an idea to reduce the actual column size of the job_name, signal_name and lock_name in order for mysql to accept the compound primary key (job_name, signal_name) in the signals table.
Reducing the size of the index has 2 problems:
- performance-hit as seen in this #2379871: White Screen of Death on admin/config.
- doesn't work on postgres (and possibly others)
I'm thinking a size of 128 each for all three. Any thoughts?
Comment #11
arnested CreditAttribution: arnested at Reload commentedFixed (by @gielfeldt) in 7.x-2.0-rc4.