Hi. I get this error immediately after installing flags.

Comments

joachim’s picture

Status: Active » Postponed (maintainer needs more info)

Can you paste the rest of the error message?

Was this a fresh install of 3.0, or were you running 2.x prior to that? If so, did you correctly update?

shabana.navas’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

I believe it happened when they upgraded from 2.x to 3.x. But once you run update.php it goes away. It basically arises due to the fact that the {flags} table has been renamed to {flag}. I think we can close this issue as it goes away when you run update.php.

alan d.’s picture

Issue summary: View changes
Status: Closed (works as designed) » Active

Confirm that this is still happening.

www.example.com/update.php was also throwing the error, and a drush updb was required to get the site working again.

Two updates

Entity API
-version = "7.x-1.2"
+version = "7.x-1.3"

Flag
-version = "7.x-2.1"
+version = "7.x-3.2"

Steps were to install the COD distribution using drush make, once installed, updated Flag from 2.x to 3.x along with Entity API minor update and hit the PDO exception when trying to run the updates.

joachim’s picture

-version = "7.x-2.1"
+version = "7.x-3.2"

I'm pretty sure it's stated in the docs that you should do the 2->3 Flag update in isolation.

alan d.’s picture

Status: Active » Closed (works as designed)

Full error in case someone else searches for it:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'flag' doesn't exist: SELECT f.fid AS fid, f.entity_type AS entity_type, f.name AS name, f.title AS title, f.global AS global, f.options AS options, fn.type AS type FROM {flag} f LEFT OUTER JOIN {flag_types} fn ON fn.fid = f.fid; Array ( ) in flag_get_flags() (line 1827 of sites/all/modules/flag/flag.module).

btw, Entity API updated didn't have updates, so I'm not sure how it was relevant, but reading between the lines, reverting status back. That and the lack of easy steps to replicate :/

joachim’s picture

I'm still not exactly sure why this problem happens.

After all, core has changed its table names from 5->6 and 6->7 and that doesn't cause explosions in the upgrade process.

But it's not something I have time to dig into, because as you say, it's quite complex to reproduce (and destructive -- you need a new site to upgrade each time you try it).

So in the meantime, we have the workaround, which I hope is clearly enough announced.

jlea9378’s picture

I'm unable to work around this problem short of uninstalling Flag 7-x-2.x before upgrading. I tried the stable release of 7.x-3.x and the dev release, and I tried both update.php and drush updb, but no matter what I keep getting the PDOException. =( I guess I will have to uninstall 7-x-2.x and then install 7.x-3.x fresh.

lpalgarvio’s picture

Version: 7.x-3.x-dev » 7.x-3.9
Priority: Normal » Major
Status: Closed (works as designed) » Active

Still happening as of today, with v3.9. Not acceptable.

A upgrade has to include a migration path.
What are your plans?

joachim’s picture

Can you provide steps to reproduce?

If this matters to you this much, can you put some time into figuring out why this is happening?

alan d.’s picture

Simple hack to bypass the error when running updates for anyone stuck here. Remove afterwards.

function flag_get_flags($entity_type = NULL, $content_subtype = NULL, $account = NULL) {
  $flags = &drupal_static(__FUNCTION__);

  if (!db_table_exists('flag')) {
    return;
  }
joachim’s picture

I started wondering whether the answer is to change this to a two-step process, but the problem IIRC is that our code expects a table we've not yet created, rather than a table we're removing.

lpalgarvio’s picture

I'm settling with the latest 7.x-2.x version for now.
When I finish the current steps of my client's site migration, I'll dive again into the 7.x-3.x upgrade, probably in the next 2 weeks.
I'll give an update when I'm back into this.

itangalo’s picture

Confirming workaround in comment 10.
Alan D++

hma66’s picture

Hi Alan,

I am referring to comment 10. Could anyone please suggest to me what needs to be done in simple plain terms as I am very new to drupal and have no knowledge of php

What needs to be removed and where. I found just half the code in flag.module file.

Thanks and regards

jenlampton’s picture

The tip from comment #10 worked for me, but after the upgrade (via the Durpal UI) I still get a failure because update 7301 failed at the rename of the flags table, but succeeded with the rename of the `flag_content` table. Since the whole update needs to be repeated, it's now failing at the rename of the `flag_content` table.

Failed: DatabaseSchemaObjectExistsException: Cannot rename flag_content to flagging: table flagging already exists. in DatabaseSchema_mysql->renameTable() (line 320 of /var/www/html/docroot/includes/database/mysql/schema.inc).

I also made the following changes to `flag_update_7301()`:

function flag_update_7301() {
  if (db_table_exists('flag_content')) {
    if (!db_table_exists('flagging')) {
      db_rename_table('flag_content', 'flagging');
    }
    else {
      db_drop_table('flag_content');
    }
  }
  if (db_table_exists('flags')) {
    db_rename_table('flags', 'flag');
  }
  // A second cache clear appears to be required here...
  cache_clear_all();
  // ...which in fact isn't enough, as the schema cache appears to need explicit
  // clearing to prevent the next updates failing to get the schema for the new
  // table names.
  drupal_get_schema(NULL, TRUE);
}
ivnish’s picture

Status: Active » Closed (outdated)
Issue tags: -Needs issue summary update

Closed as outdated because Drupal 7 is EOL