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.
Started having these after 7.x-1.x-dev to 7.x-2.x-dev upgrade:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table '[db_name].cache_libraries' doesn't exist: DELETE FROM {cache_libraries} WHERE (expire <> :db_condition_placeholder_0) AND (expire < :db_condition_placeholder_1) ; Array ( [:db_condition_placeholder_0] => 0 [:db_condition_placeholder_1] => 1302282520 ) in cache_clear_all() (line 169 of /var/www/my_site/includes/cache.inc).
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table '[db_name].cache_libraries' doesn't exist: TRUNCATE {cache_libraries} ; Array ( ) in cache_clear_all() (line 169 of /var/www/my_site/includes/cache.inc).
Comment | File | Size | Author |
---|---|---|---|
#15 | cache_update_2.patch | 546 bytes | tstoeckler |
#8 | cache_update.patch | 492 bytes | tstoeckler |
Comments
Comment #1
sunThanks for testing. Obviously we forgot to add a module update in the commits last night. ;)
Comment #2
klonos...for whatever it's worth, a classic routine of disabling -> uninstalling -> re-enabling the module makes the issue go away. Let's just fix things for all others that will upgrade though. Thanx ;)
Comment #3
dlthomas CreditAttribution: dlthomas commentedI'm getting this error too but not sure what has happened to my website.. I can't get into modules panel to disable it and all of my pages are doubled with the maintenance page..
Comment #4
klonosHey David. The proper, suggested way of upgrading modules/themes to their next *major* version (for example from 1.3 to 2.0) is:
1. Disable the old version.
2. Uninstall the old version.
3. Remove the old version's directory from your ../sites/all/modules/
4. Extract the new version to your ../sites/all/modules/
5. Enable the new version.
This of course is not required in *minor* version upgrades (1.3 to 1.4 for example). What you and I both did was an 'in-place' upgrade, skipping the above mentioned steps.
Usually, if the maintainers make sure there is an "upgrade path" or some kind of "migration steps", one can safely do in-place upgrades and all they are required to do is simply run a database update script. This is a dev version though and -as Daniel already explained in #1- they simply forgot to do this in the last dev build (it will be fixed for others though). I am sure it wouldn't happen in a stable release, but since you and I both use dev versions I take it we are prepared to take risks like that.
Bottom line is that if you follow my instructions in #2, you'll get out of trouble. You can manage your modues in http://your.site.net/admin/modules (or http://your.site.net/en/admin/modules if your site is multilanguage and you use path prefix - replace the "en" part of the path with another language if you don't have English enabled).
Comment #5
sunerr... the upgrade path that @klonos outlined is only required for Drupal core upgrades, not for major version upgrades in contributed modules.
And even for Drupal core upgrades, it only involves disabling, not uninstalling. Uninstalling removes all of your data, so if you do that, then there's nothing in your database could be updated or upgraded any longer.
Comment #6
klonos...I knew that. All the libraries module does is provide a way for other modules to locate libs placed in a central place (directory). No data saved someplace as far as I know, so no loss. I didn't mean to generalize it for all contrib modules - sorry if I did.
Comment #7
dlthomas CreditAttribution: dlthomas commentedThanks both - I managed to unistall it after awhile and get it working using @klonos instructions. I think part of my problem is my server's memory is set quite low.. I kept getting an error message to do with that whenever I clicked the modules link.. and another about a function not being defined (I didn't write down which function sorry)
Comment #8
tstoecklerSorry for forgetting that.
Here's a patch which should fix the problem. I haven't tried it out yet, but will do so now.
I know Drupal core has a @defgroup for update functions, do we want that, too, or do we re-use that with @ingroup, or something else?
Comment #9
tstoecklerWell, manually testing the upgrade works.
Now since libraries doesn't store any data, and, hence, uninstalling and re-installing doesn't lead to data loss, I'm going to leave this for another review before committing.
Comment #10
angelbreath CreditAttribution: angelbreath commentedI uninstalled-reinstalled it , seems to work , but after 2-3 refreshes of Firefox , same problem again. Actually dont be sure how to use the cache_update.patch , so the uninstall-install method not works.
Comment #11
tstoecklerCan you elaborate on that? The described bug is a database problem, so it would be very awkward if the browser had anything to do with that.
Sorry, but I don't quite understand that. Are you having problems with the patch? And what didn't work?
Comment #12
sunUpdate functions are an exception to the phpDoc summary rule... they are displayed to the end-user in the sense of what is being done in an update, so we use first-person ("Create" instead of "Creates")
In case we're going to backport 2.x to D6 at some point later in time, we should wrap this in a !db_table_exists() - which is a best practice for contrib anyway.
Powered by Dreditor.
Comment #13
joergM CreditAttribution: joergM commentedpatch from #8 works fine for me!
Thx tstoeckler for the delivery :-)
Jörg
Comment #14
TimelessDomain CreditAttribution: TimelessDomain commentedPatch from #8 fixed problem. I did not have to use steps recommended in #4
Comment #15
tstoecklerHere we go. Going to test this once more and wait for the bot and then commit.
Comment #16
tstoecklerPasses manual test.
Comment #17
tstoecklerhttp://drupal.org/commitlog/commit/10030/aea3addfb1d165b7a219ef52c9a492b...
Committed to master.
Comment #19
bleen CreditAttribution: bleen commentedI just downloaded a fresh copy of 7.x-2.x-dev, ran "drush en libraries -y" and got the same error as the original post
Comment #20
bleen CreditAttribution: bleen commentedhmm .. 7.x-1.x must not have been uninstalled properly. Once I ran "drush updb" everything was fine
Comment #21
shabana.navas CreditAttribution: shabana.navas commentedComment #22
klonos...you deleted your post, then I'm sure you also meant to revert this to its former 'closed-fixed' status too.
Comment #23
chrisjlee CreditAttribution: chrisjlee commentedFixed. Patch in current 2.0x version. Ran update db.
Comment #24
attheshow CreditAttribution: attheshow commentedYes, this error still exists. I'm using drush make to do an automatic upgrade to d7 on a site and drush reports this error when running "drush en libraries -y". My d6 site is using 6.x-1.0 and I've got drush make downloading 7.x-2.0-alpha2. I may try having my upgrade script uninstall libraries and disable the modules that depend upon it, then re-enable both. Maybe that'll work...
Comment #25
tstoecklerSimply run update.php before enabling libraries, that should work. Marking this back closed.
If there is some problem related to Libraries API please open a new issue.