Column owner not created in rules_config on update 2.3 to 2.5

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

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

Same issue here...

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';"

This could be related to #2093505: Rules thinks installed version is 2.3 when it's 2.5 - seeing that an update-hook is in place to add the column: http://drupalcode.org/project/rules.git/blob/refs/heads/7.x-2.x:/rules.i...

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

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

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

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

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.

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?

Thanks @Ryan.

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

see #1568134: Enabling or disabling a contrib rule makes it disappear

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

Thank You tons #4

so much thx #4!

Many thanks to guillaumev for #4

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

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.

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

forgot 'field' in the array

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

Changing the logic so it would use the existing constant

Yes, good catch.

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

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?

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.

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.

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.

#4 saved my ass. Thanks.

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.

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

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.

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

Fix works for me (on 7.x-2.9).

#43 and the previous similar patches (#39, #38, #28, #27, #25, #22) are definitely not the correct thing to do. hook_schema() in only called when the module is installed and uninstalled, NOT when the module is updated. hook_schema() MUST have the most current up-to-date schema definition at all times and must NOT have conditional code referencing different schema versions or update functions. This is what @fago was implying in #31.

Likewise, if Rules is being install for the first time, then hook_schema() is run and properly creates the owner column, and the hook_update_N() functions (specifically update 7211) are NOT run. So again, there should be no problem.

I really don't understand what problem this is trying to correct or why this is still a problem. Older databases will have the owner column added by update 7211 when update.php is run. If your Rules codebase doesn't contain update 7211, then you don't need the owner column.

"Unknown column 'base.owner'" implies update.php wasn't run. "Cannot add field rules_config.owner: field already exists" implies that update.php was already run and 7211 already created the column - 7211 should not be running a second time, but if it does for some weird reason then the fix @fago put in in #10 prevents that error.

I find it curious that most of the error message mention commerce modules - perhaps some commerce-provided rules were written to use a more recent version of Rules, or perhaps the commerce modules were update before the Rules module, or something like that. #2090511-191: <7.x-2.4 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found" discusses how this can happen because of update dependencies. #2090511: <7.x-2.4 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found" in general discusses workarounds for update failures caused by the major disruptive changes that were taking place in a number of different modules back then.

If you don't run update.php, then yeah you'll get an error. And if you didn't put your site into maintenance mode before the update I suppose some Rules could be triggered before the column is added and again you'll get an error. But putting your site in maintenance mode is one of the documented steps for updating Drupal modules, so ...

Regardless, Rules 2.5 is more than 5 years old and less than 5% of Rules sites are still using a version <=2.5. If you are trying to upgrade from one of those versons, then follow the instructions at https://www.drupal.org/docs/7/update/updating-modules . If you encounter problems, workarounds are given above and in #2090511: <7.x-2.4 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found".

There is so much wrong information in this issue that I don't find it helpful to keep it open. If your problems are not solved by my suggestions above, then please open a new issue with details of what you're trying to do and how you're trying to do it.