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.
neither the rc, or the dev creates the autoload tables in the db when installing it. I wonder if most people are upgrading from 1.x and that's why I didnt see a issue already???
Here is a cut and paste of my attempt to install autoload 2.x-dev:
me@mydomain.com [~/public_html/live/sites/all/modules]# drush dl autoload-6.x-2.x-dev Project autoload (6.x-2.x-dev) downloaded to [success] /home1/me/public_html/live/sites/all/modules/autoload. me@mydomain.com [~/public_html/live/sites/all/modules]# drush en autoload The following projects will be enabled: autoload Do you really want to continue? (y/n): y WD php: Table 'mydomain1_live.autoload_registry_file' doesn't exist [error] query: SELECT * FROM autoload_registry_file in /home1/me/public_html/live/sites/all/modules/autoload/autoload.registry.inc on line 126. autoload was enabled successfully. [ok] Table 'mydomain_live.autoload_registry_file' doesn't exist [error] query: SELECT * FROM autoload_registry_file in /home1/me/public_html/live/sites/all/modules/autoload/autoload.registry.inc on line 126. An error occurred at function : drush_pm_enable [error] me@mydomain.com [~/public_html/live/sites/all/modules]#
Comment | File | Size | Author |
---|---|---|---|
#14 | autoload-943168-remove_defaults_for_fields_in_primary_key-14.patch | 926 bytes | PatchRanger |
Comments
Comment #1
Dave ReidDid you run update.php?
Comment #2
halohaloplace CreditAttribution: halohaloplace commentedSame problem. Updating did not help.
Comment #3
Dave ReidDo you happen to have the Notifications or Messaging modules enabled?
Comment #4
javlinsharp CreditAttribution: javlinsharp commentedI have the same error. I do not have Notification nr Messaging modules installed. Able to provide additional information as requested.
Comment #5
zvischutz CreditAttribution: zvischutz commentedHi All,
I had the same problem because I had mail system installed and a new version requires the autoload . So after I put the module files in directory it "enabled" it automatically without creating it.
Indeed no tables were created in db.
I just disabled and reenable it and the tables were created.
Reminds the joke about the difference between the computer industry and the vehicles industry ...
but it helps
Comment #6
eighthourlunch CreditAttribution: eighthourlunch commentedI'm still seeing this issue with 6.x-2.1. I've tried several different things and can't for the life of me get it to create the tables. Rolling back to 6.x-1.4 for now, but would love to see this addressed.
Comment #7
baff CreditAttribution: baff commentedsubscribe
autoload_registry' doesn't exist
Rolling back to 6.x-1.4 too
Comment #8
Jene.Gladstone CreditAttribution: Jene.Gladstone commentedI have just applied all up to date core and modules to our website, and am having this same issue with this table not existing. I cannot see a resolution to this issue on Drupal.org. The post #5 above seems hopeful, but I cannot seem to disable/re-enable any applicable modules. Any advice? Wondering what the timeframe is for this issue to be addressed?
Comment #9
Jene.Gladstone CreditAttribution: Jene.Gladstone commentedComment #10
hefox CreditAttribution: hefox commentedDoes manually running
work?
Cause that's all autoload is doing, which is how all drupal modules install it's tables. a hook_install with a drupal install schema.
We're not having this problem and regularly deploy this module.
Comment #11
sp3boy CreditAttribution: sp3boy commentedHaving the same problem when first enabling autoload 6.x-2.1 in D6.26.
Multiple occurrences in dblog of
Table '[dbname].autoload_registry' doesn't exist query: SELECT filename FROM autoload_registry WHERE name = 'views_plugin_display_default' AND type = 'class' in [site home]/sites/default/modules/contrib/autoload/autoload.module on line 191
or
Table '[dbname].autoload_registry' doesn't exist query: SELECT filename FROM autoload_registry WHERE name = 'date_plugin_display_attachment' AND type = 'interface' in [site home]/sites/default/modules/contrib/autoload/autoload.module on line 191.
No tables are created in the database at this point.
Disabling and uninstalling generates dblog errors when attempting to drop the tables.
The module's row in {system} is of course not deleted by the uninstall, and it has the revised weight value of -100.
Re-enabling the module successfully creates the tables. Is that because the necessary weight value (which is originally set in hook_enable) is already present, whereas for a "true" first install scenario, the system row will have a default weight because hook_enable has never run?
At the moment I don't know enough about Drupal internals to predict how the weight of a module influences the install processing, bearing in mind I have not been trying to install multiple modules with the same admin page action.
Update at 16:38 - as suggested by previous comments, installing a vanilla D6 system and then installing just the autoload module does not cause a problem. However the list of modules running in my production Drupal site is a very long one so I will try to narrow down the possible conflicts.
Comment #12
sp3boy CreditAttribution: sp3boy commentedOK I've ended up making a copy of my live Drupal site and temporarily putting a debug_traceback into the actual watchdog function. I could reproduce the problem at will if I reloaded the db export and ran the autoload install. The traceback indicated that
class_exists
was being run and invoking autoload_class via spl_autoload_call before the schema tables were created and populated.However I also discovered that my database {system} table had an old row in it for autoload with the unlikely weight of -282828 which I suspect was hacked by my predecessor. Once I deleted the suspect row before re-running the install, I was not getting the error during install.
So as my solution appears to be achieved by cleaning up dubious old database content, I won't be spending more time on trying to reproduce the problem on a generic D6 system.
However I hope my comments may be helpful to anyone having a similar problem.
Comment #13
shark CreditAttribution: shark commentedrunning the following on the command line worked for me:
drush eval "drupal_install_schema('autoload')"
Comment #14
PatchRanger CreditAttribution: PatchRanger commentedI got this situation too.
The problem is due to MySQL weird behavior, which is described here: #819524: Database schema check on primary key (unique) + default combination.
Also are related:
Solution is just to remove
'default' => '',
for fields of the primary key.Here is the patch, that fixes it.