PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal_distro_xxx.flag' doesn't exist: SELECT name, title FROM {flag}; Array
in flag_entity_info() (line 38 of /vagrant/repos/xxx/modules/contrib/flag/flag.module).

This error occurs when building a site with a distro and make file. The updates that rename the table names (flag_update_7301 etc) never get run because the above error occurs before that point. This is because when Drupal is bootstrapping, it is trying to access tables based on the Flag 2 schema with Flag 3 code. I have fixed this locally and will add a patch here shortly.

#29 schema_check-1870300-28.patch1.5 KBstefan.r
PASSED: [[SimpleTest]]: [MySQL] 448 pass(es). View
#1 schema_check-1870300-1.patch1.6 KBblairski
PASSED: [[SimpleTest]]: [MySQL] 448 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


blairski’s picture

1.6 KB
PASSED: [[SimpleTest]]: [MySQL] 448 pass(es). View

Here the patch for the issue. The problem area is the implementation of hook_entity_info(), which is doing a query on the flag table. It is doing this before the update has run, so the tables have not been renamed yet. So on sites where Flag 2.0 existed before, the table is called flags, not flag. This results in a fatal error.

So the patch checks the schema version and if it is less than 7300, then the DB is still running Flag 2.0 tables, so it skips the query on the flag table. The update then runs and the tables are renamed correctly. After that point, the schema version will always be greater than 7300, so the rest of the code will run as normal.

This may not the best way to tackle the issue, but it works. :)

joachim’s picture

Version: 7.x-3.0-alpha4 » 7.x-3.x-dev
Priority: Normal » Critical

Yowsers. That's a nasty bug.

Not a terribly nice fix either though!

At the very least, I'd rather we used db_table_exists() instead of coding hook_update_N numbers into this part of the module.

But going further than that, why is hook_entity_info() getting invoked at this point? Is it core, or another module, or flag itself?

Leksat’s picture

I also had this bug. It occurred because before update I cleared caches. I used drush for update.
There are huge places where hook_entity_info is called if caches are cleared (and if you have big amount of enabled modules).

I solve the problem like so:

  1. while having flag 2.x installed I went to update.php (so all caches which used on this page was set up),
  2. updated flag code to 3.x version,
  3. refreshed update.php page,
  4. performed updates.

With this workflow all updates was performed succesfully.

joachim’s picture

> because before update I cleared caches.

What if you don't clear caches before update?

Leksat’s picture

In my case it's not possible because of special deployment process. But the steps provided in #3 are basically the same as if I wouldn't clear caches.

joachim’s picture


joachim’s picture

Status: Active » Closed (works as designed)

Just tested the update on my test Flag 2.x site. All works fine for me.

The problem is therefore only caused when you clear caches with the new code in place. Don't do that -- it's bound to be a disaster. Clear caches before you put new code in, and once new code is there, go STRAIGHT to update.php. Nothing else in Drupal can deal with the unstable state the system is in at that point.

(Feel free to update the core docs on running updates with this information! :)

blairski’s picture

Thanks for the update on the workflow. We don't run these steps manually, everything is done in build scripts. We will need to go and check the steps and see if cache is cleared before drush updb. The other problem is that some module updates (custom and contrib) will programatically clear cache for a variety of reasons and if that update is fired before the flag update that changes the tables, the error will still occur. We can't control that.

joachim’s picture

Title: Upgrade from Flag 2 to Flag 3.0-alpha4 fails » Upgrade from Flag 2.x to Flag 3.x can fail if other update hooks clear cache
Status: Closed (works as designed) » Active

> The other problem is that some module updates (custom and contrib) will programatically clear cache for a variety of reasons

That's a fair point. I can add something to the update notes to say that the Flag 2.x -> 3.x update should be done separately from other modules.

alesr’s picture

Is this the only issue blocking Flag from 7.x-3.0 stable release?

joachim’s picture

I'm giving #1965040: change handling of return values from hook_flag_access() a bit more time, as if it doesn't get in now it's pushed to D8. It's a fairly small reroll if you can help! After that, yup, we're ready for 3.0!

This issue I think can only be 'fixed' with documentation -- instructions in the upgrade notes to upgrade Flag separately from other modules.

alesr’s picture

I rerolled the patch from #1965040-8 here http://drupal.org/node/1965040#comment-7407694
The main part of the patch ($access_array check in flag_flag.inc) is basically the same, which means that we're close ;)
Please review.

joachim’s picture

Component: Flag core » Documentation
Issue tags: -7.x-3.0 release blocker

I've added a link to this from the release notes. I'm pondering writing an 'upgrade' section in the docs, but I suspect nobody will ever read it...

markbannister’s picture

Updated from 2x to 3xrc1 and get this error. Updated with drush.
Database update seemed to go OK. Now I get the PDOexception error when logging in.
Tried the patch referenced in 12 https://drupal.org/node/1870300#comment-7407832 but it seemed to be already in place.
Organic groups installed. Did I miss something?

BTW, site is hosed at the moment from this... how does one undo or redo the database update?

joachim’s picture

If you get that error after update, then the update did NOT work well!
Did you update any other modules with drush at the same time?

best thing now is to wipe the site and try again with a new dev copy. Make sure you only run the flag update.

markbannister’s picture

Afraid of that. Only did the flag update.
This sucks, cause last week sometime cron stopped working and I don't have daily backups from Backup and Migrate. Teaches me not to double check. No too much work but still a pain.

joachim’s picture

You really must try updates - or indeed any code change - on a dev copy!
you can always force the flag updates to run, see if that fixes it

thing is, I need users with this problem to try reproducing it so we can figure it out, and that means dev copies!

markbannister’s picture

Went through all this mess I deleted below but then was able to revert back to 2x version. Pretty sure I made a mess of it but it seems to be working AND more importantly lots of other issues went away I was having with commons including (https://drupal.org/node/1850798).

Disabled all these modules with drush: flag, message_subscribe, commons_follow, commons_activity_streams, commons_follow_node, commons_events, commons_events_pages, commons_follow_group, commons_follow_term, commons_follow_user, message_subscribe_ui, commons_follow_ui, commons_groups_pages, commons_activity_streams_groups, commons_groups_directory, message_subscribe_email, commons_notify, flag_abuse, commons_user_profile_pages, commons_site_homepage, commons_activity_page, og_mailinglist_flag

I deleted all flag tables
I recreated flag tables 2.1 from mysql backup (left them empty)
set schema_version to 0 in system table
downloaded flag 7.x-2.1
enabled flag with drush
enabled all other modules I disabled
updated db with drush updatedb

So how do I run the updates again?
OK, set scheme_version for flag in System table to 7000 (was 7306 new value after update 7201). Ran updatephp , ten updates,
7201 - Clear caches.
7202 - Clean-up flag records for deleted nodes and comments.
7203 - Add an index to help with view's flag_handler_relationship when not required.
7300 - Rebuild the class registry due to classes moving files.
7301 - Rename {flag_content} table to {flagging} and {flags} table to {flag}.
7302 - Rename database columns on the {flag} table.
7303 - Rename database columns on the {flagging} table.
7304 - Rename database columns on the {flag_counts} table.
7305 - Convert flag roles to permissions.
7306 - Convert flag view modes settings.

error message:
Update #7202
Failed: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dev1collaboration.flag_content' doesn't exist: DELETE FROM {flag_content} WHERE content_type = 'node' AND NOT EXISTS (SELECT 1 FROM {node} n WHERE content_id = n.nid); Array ( ) in flag_update_7202() .. flag.install).

added empty table flag_content back (using sql data from an old backup)
The following updates returned messages
flag module
Update #7202
Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'content_type' in 'where clause': DELETE FROM {flag_counts} WHERE content_type = 'node' AND NOT EXISTS (SELECT 1 FROM {node} n WHERE content_id = n.nid); Array ( ) in flag_update_7202() (line 396 of /home/sites/drupal7/public_html/sites/all/modules/flag/flag.install).

and still getting this:
Notice: Undefined property: flag_node::$content_type in flag_abuse_views_default_views() (line 12 of /home/sites/drupal7/public_html/profiles/commons/modules/contrib/flag_abuse/includes/flag_abuse.views_default.inc).
Notice: Undefined property: flag_comment::$content_type in flag_abuse_views_default_views() (line 12 of /home/sites/drupal7/public_html/profiles/commons/modules/contrib/flag_abuse/includes/flag_abuse.views_default.inc).

joachim’s picture

It seems you're back on 2.x now.
could you try the upgrade from 2 to 3 to see what went wrong - on a dev copy of course.

roberto_araya’s picture

I have the same problem, with 7.x-3.0-rc1 and 7.x-3.0-alpha4.

joachim’s picture

Could you give more detail? Did you try the workaround? Did the workaround work for you?

taecelle’s picture

I'm very sorry, but is there somewere a strict instrustion how to upgrade from 2.1 to 3.1?? Don't want to make many mistakes...

joachim’s picture

See the 3.x release: https://drupal.org/node/1699646

Feel free to add something to the docs pages!

taecelle’s picture

mmm... thank you, but i still don't see how to do it in steps.
I must disable flag 2.1 and what then? Just install 3.1 version??

joachim’s picture

Don't disable the module.
You maybe need to read the general instructions for upgrading a contrib module?

DamienMcKenna’s picture

Issue summary: View changes

+1 for using the patch as a temporary fix.

Jody Lynn’s picture

I manage to get the error on a fresh install of a profile (no flag update). Patch fixes it. At the point that the error happens, flag's system status is 1 but the schema_version is still -1.

stefan.r’s picture

Status: Active » Needs review

Even taking into account we have a workaround with the specific upgrade instructions, shouldn't the patch in #1 be committed regardless?

stefan.r’s picture

1.5 KB
PASSED: [[SimpleTest]]: [MySQL] 448 pass(es). View

This patch uses db_table_exists() as requested by the maintainer.

joachim’s picture

Closed a duplicate issue, which mentions that this is actually caused by a core bug: #1311820: Don't do a registry_update() before installing a module.

So the check for the presence of the table in the patch should have a comment with the URL of that issue, explaining that we're working around a core bug.

Tagging this as blocking the next release.

Anonymous’s picture

Looking at this I am not sure if there's anything I can do here - #1311820: Don't do a registry_update() before installing a module was RTBC'd 6 days ago so presumably just waiting for that? Let me know if I can...

joachim’s picture

Status: Needs work » Fixed

Just needs a comment adding to the patch, which I've done now.


  • joachim committed c59c49d on 7.x-3.x authored by stefan.r
    Issue #1870300 by blairski, stefan.r: Added workaround for core bug...

Status: Fixed » Closed (fixed)

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