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).
CommentFileSizeAuthor
#15 cache_update_2.patch546 byteststoeckler
#8 cache_update.patch492 byteststoeckler
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Priority: Normal » Major

Thanks for testing. Obviously we forgot to add a module update in the commits last night. ;)

klonos’s picture

...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 ;)

dlthomas’s picture

I'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..

klonos’s picture

Hey 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).

sun’s picture

err... 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.

klonos’s picture

...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.

dlthomas’s picture

Thanks 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)

tstoeckler’s picture

Status: Active » Needs review
FileSize
492 bytes

Sorry 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?

tstoeckler’s picture

Well, 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.

angelbreath’s picture

I 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.

tstoeckler’s picture

but after 2-3 refreshes of Firefox , same problem again

Can 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.

Actually dont be sure how to use the cache_update.patch , so the uninstall-install method not works.

Sorry, but I don't quite understand that. Are you having problems with the patch? And what didn't work?

sun’s picture

Status: Needs review » Needs work
+++ b/libraries.install
@@ -13,3 +13,11 @@ function libraries_schema() {
+ * Creates the 'cache_libraries' table.

Update 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")

+++ b/libraries.install
@@ -13,3 +13,11 @@ function libraries_schema() {
+  $specs = drupal_get_schema_unprocessed('system', 'cache');
+  db_create_table('cache_libraries', $specs);

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.

joergM’s picture

patch from #8 works fine for me!
Thx tstoeckler for the delivery :-)
Jörg

TimelessDomain’s picture

Patch from #8 fixed problem. I did not have to use steps recommended in #4

tstoeckler’s picture

Status: Needs work » Needs review
FileSize
546 bytes

Here we go. Going to test this once more and wait for the bot and then commit.

tstoeckler’s picture

Status: Needs review » Reviewed & tested by the community

Passes manual test.

tstoeckler’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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

bleen’s picture

Status: Closed (fixed) » Needs work

I 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

bleen’s picture

Status: Needs work » Closed (fixed)

hmm .. 7.x-1.x must not have been uninstalled properly. Once I ran "drush updb" everything was fine

shabana.navas’s picture

Status: Closed (fixed) » Active
klonos’s picture

Status: Active » Closed (fixed)

...you deleted your post, then I'm sure you also meant to revert this to its former 'closed-fixed' status too.

chrisjlee’s picture

Fixed. Patch in current 2.0x version. Ran update db.

attheshow’s picture

Status: Closed (fixed) » Active

Yes, 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...

tstoeckler’s picture

Status: Active » Closed (fixed)

Simply 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.