On an update on a live site from version 2.3 to 2.5, the owner field in the rules_config table, the logged error was:

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.owner' in 'field list': SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.owner AS owner, base.access_exposed AS access_exposed, base.data AS data FROM {rules_config} base WHERE (base.name IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => commerce_tax_rate_btw ) in EntityAPIController->query() (regel 187 van /home/xxx/bachkoorholland.nl/html/bachkoorholland.nl/sites/all/modules/entity/includes/entity.controller.inc).

This error didnt show up on running update.php

Adding the column manually with the schema information from rules.install solved the error.

Files: 
CommentFileSizeAuthor
#43 column_owner_not-2094879-43.patch1.83 KBvinmassaro
#39 2094879-column_owner_not_created-39.patch1.4 KBwebdrips
#38 2094879-column_owner_not_created-38.patch1.56 KBKhalid S
#28 2094879-column_owner_not_created-28.patch1.33 KBextremal
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es). View
#27 2094879-column_owner_not_created-27.patch1.32 KBextremal
PASSED: [[SimpleTest]]: [MySQL] 355 pass(es). View
#25 2094879-column_owner_not_created-25.patch1.27 KBmarcelovani
FAILED: [[SimpleTest]]: [MySQL] 7 pass(es), 7 fail(s), and 0 exception(s). View
#22 2094879-column_owner_not_created-21.patch1.26 KBmarcelovani
FAILED: [[SimpleTest]]: [MySQL] 350 pass(es), 1 fail(s), and 0 exception(s). View
#20 2094879-column_owner_not_created-20.patch756 bytesgirishmuraly
FAILED: [[SimpleTest]]: [MySQL] 351 pass(es), 0 fail(s), and 147 exception(s). View

Comments

radimklaska’s picture

Same here. Adding owner column to rules_config table manually fixed the problem.

My error msg:

WD menu: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.owner' in 'field list': SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.owner AS owner, base.access_exposed AS access_exposed, base.data AS data FROM {rules_config} base WHERE (base.name IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => commerce_shipping_method_flat_rate ) in EntityAPIController->query() (line 187 of /xxx/sites/all/modules/contrib/entity/includes/entity.controller.inc).
WD php: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.owner' in 'field list': SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.owner AS owner, base.access_exposed AS access_exposed, base.data AS data FROM {rules_config} base WHERE (base.name IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => commerce_multicurrency_use_czk ) in EntityAPIController->query() (line 187 of /xxx/sites/all/modules/contrib/entity/includes/entity.controller.inc).
barbank’s picture

Yes varchar(255) - I just wish things like this don't happen

guillaumev’s picture

Same issue here...

guillaumev’s picture

To save some time to people wanting to add the column manually:

drush sqlq "ALTER TABLE rules_config ADD owner VARCHAR(255) NOT NULL DEFAULT 'rules';"
lsolesen’s picture

radimklaska’s picture

@lsolesen I think you are right. I had to comment out rules_update_7211() for following update.

ptmkenny’s picture

I'm having the same problem with a production site on Pantheon. When I update locally in MAMP, #7211 applies fine.

However, when I try to update on Pantheon, it keeps prompting me to re-apply it. I also got the following error:

Update #7211

Failed: DatabaseSchemaObjectExistsException: Cannot add field rules_config.owner: field already exists. in DatabaseSchema_mysql->addField() (line 328 of /srv/bindings/a6b39b59d7734fb380f413e5e2d1a87d/code/includes/database/mysql/schema.inc).

radimklaska’s picture

@ptmkenny If you added owner column manually (or just check if it's already there), you need to comment out rules_update_7211() for following update.

Ben Finklea’s picture

Thank you, guillaumev! #4 worked great for me and saved a lot of time.

fago’s picture

Status: Active » Fixed

ad #7: I've commit a fix to the dev branch which should allow you to run rules_update_7211() even if the column already exists.

@others: Have you run into update problems earlier, before the owner column has been missing? But yes, manually executing the update is probably the best thing to do:


/**
 * Creates the "owner" column.
 */
function rules_update_7211() {
  // Create a owner column.
  if (!db_field_exists('rules_config', 'owner')) {
    db_add_field('rules_config', 'owner', array(
      'description' => 'The name of the module via which the rule has been configured.',
      'type' => 'varchar',
      'length' => 255,
      'not null' => TRUE,
      'default' => 'rules',
    ));
  }
}

So closing this for now. If it turns out more people ran into this, we can re-open and commit another update function.

girishmuraly’s picture

Status: Fixed » Active

Sorry to reopen but the initial bug report states that the column does not exist when trying to run update 7211. The fix in #10 is to prevent errors when the column already exists, not when it does not. I am getting the same problem in #0 on 2.3 -> 2.5 upgrade. The fix in #10 does not fix it for me. I think there is a cache problem which we need to fix before the update is run?

Ryan Weal’s picture

@girishmuraly you might want to take a look at my comment here: https://drupal.org/node/2090511#comment-7994193

It looks like at some point I had missed one of the earlier updates before 7211 that was causing my troubles... so I just tried to re-run everything after 7200 until it worked.

girishmuraly’s picture

Thanks @Ryan.

I've posted in https://drupal.org/node/2090511#comment-7995885 that manual workarounds cannot work for me unfortunately.

fago’s picture

Jim Ruby’s picture

I do not use drush, could someone please provide a manual fix that I can do using phpmyadmin?
I was upgrading from 7.20 to 7.dev and there was two items in the list when running the update.php and I did not put my site in maintenance mode. the error I received looks the same:

Error message
PDOException
: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.owner' in 'field list':
SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin,
base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS
dirty, base.module AS module, base.owner AS owner, base.access_exposed AS access_exposed,
base.data AS data
FROM
{rules_config} base
WHERE (base.status IN (:db_condition_placeholder_0, :db_condition_placeholder_1,
:db_condition_placeholder_2)) ; Array
(
[:db_condition_placeholder_0] => 3
[:db_condition_placeholder_1] => 2
[:db_condition_placeholder_2] => 6
)
in
EntityAPIController->query() (line 187
of
/home/7/public_html/sites/all/modules/entity/includes/entity.controller.inc).
The website encountered an unexpected error. Please try again later.

Thank you

podarok’s picture

Issue summary: View changes

Thank You tons #4

marcoka’s picture

so much thx #4!

kamenrs’s picture

Many thanks to guillaumev for #4

crazysas’s picture

Sorry, but if I haven't DRUSH, what I must input to MySQL?

girishmuraly’s picture

Version: 7.x-2.5 » 7.x-2.x-dev
Status: Closed (duplicate) » Needs review
FileSize
756 bytes
FAILED: [[SimpleTest]]: [MySQL] 351 pass(es), 0 fail(s), and 147 exception(s). View

Sorry to reopen this but I am not seeing this fixed in the latest dev version and I think the description in #1568134: Enabling or disabling a contrib rule makes it disappear is confusing. I am seeing the issue report here (i.e. 'Column not found' error) when upgrading from version 2.3 to 2.7 (which includes the fix from #1568134: Enabling or disabling a contrib rule makes it disappear).

My problem stems from the fact when Rules is upgraded to > 2.3, if a bootstrap occurs before updatedb, this error shows up. It could be something as inconspicous as a `drush vget` or a `drush rr` that is run before `drush updatedb` that triggers it.

Attaching the patch that solves this for me, which will help prevent checks to the table where the column has not yet been created. Reviews/feedback welcome.

Status: Needs review » Needs work

The last submitted patch, 20: 2094879-column_owner_not_created-20.patch, failed testing.

marcelovani’s picture

FileSize
1.26 KB
FAILED: [[SimpleTest]]: [MySQL] 350 pass(es), 1 fail(s), and 0 exception(s). View

Trying a different approach by only adding the field to the schema array after the update hooks have run

marcelovani’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 22: 2094879-column_owner_not_created-21.patch, failed testing.

marcelovani’s picture

Status: Needs work » Needs review
FileSize
1.27 KB
FAILED: [[SimpleTest]]: [MySQL] 7 pass(es), 7 fail(s), and 0 exception(s). View

forgot 'field' in the array

Status: Needs review » Needs work

The last submitted patch, 25: 2094879-column_owner_not_created-25.patch, failed testing.

extremal’s picture

FileSize
1.32 KB
PASSED: [[SimpleTest]]: [MySQL] 355 pass(es). View

Small amendment to the patch to make it working in situations when the rules module is being installed

extremal’s picture

Status: Needs work » Needs review
FileSize
1.33 KB
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es). View

Changing the logic so it would use the existing constant

marcelovani’s picture

Yes, good catch.

jwilson3’s picture

Status: Needs review » Reviewed & tested by the community

patch in #28 works perfectly. Thank you @extremal and @marecelovani.

fago’s picture

Status: Reviewed & tested by the community » Closed (works as designed)

Attaching the patch that solves this for me, which will help prevent checks to the table where the column has not yet been created. Reviews/feedback welcome.

I don't think that this is a good solution in the problem, as it's not how the drupal update system works. Yes, your site might be broken until you run update.php once you updated the code, this is how the update system works. If there are not any good reasons to make rules behave differently, we should stick with the way drupal works and require people to run update.php.

It could be something as inconspicous as a `drush vget` or a `drush rr` that is run before `drush updatedb` that triggers it.

Maybe, still - there shouldn't be any harm in it either when you can update.php and it works?

ivanjaros’s picture

I just stumbled upon this issue. What's the issue with drush? Why do I "have" to run update.php manually?

marcelovani’s picture

The problem we are trying to solve is that the update hook in question is trying to use a field that is not in the database yet. It will only be on the database once the hook schema is run. In #28 we put a fix to stop trying to do anything to a field that doesn't exist.
The way I replicate the problem is upgrading rules from an older version and running drush updb.

ivanjaros’s picture

So it is an issue with order of hooks?

marcelovani’s picture

It is. In other words, the hook_schema is running before the hook_update kicks in and creates the field.
What my patch (#25, amended on #27) does is to delay the reference to the field (owner) until the updates run.

BrightBold’s picture

Status: Closed (works as designed) » Needs work

I got this error while running update.php (not because I failed to run it as suggested in #31), so it doesn't seem to me that this is "works as designed." Although my database does now have an "owner" column (presumably created in a subsequent database update?) so I guess the problem is solved for me.

Forgive me if I'm misunderstanding and shouldn't have reopened this, but it seems to me that you don't want the update process to be generating errors by design.

Chris Gillis’s picture

#4 saved my ass. Thanks.

Khalid S’s picture

This patch is same as #28, but for upgrading from 7.x-2.3 to 7.x-2.9.

But once your module is updated, you don't need to keep these changes for next update.

webdrips’s picture

Same patch as #38, but corrected for path (should be local to rules module wherever it is, not from your document root).

vinmassaro’s picture

Status: Needs work » Reviewed & tested by the community

Ran into this bug upgrading from Rules 7.x-2.2 to 7.x-2.9. Tested the patch in #39, works well, moving to RTBC.

The last submitted patch, 38: 2094879-column_owner_not_created-38.patch, failed testing.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 39: 2094879-column_owner_not_created-39.patch, failed testing.

vinmassaro’s picture

Status: Needs work » Needs review
FileSize
1.83 KB

Rerolling #39 into a git aware patch to see if it passes.