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
#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:

<?php
/**
 * 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
StatusFileSize
new756 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

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

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