broke my drush? Column not found 'base.default_state' in 'field list'

I received same error after update. Crashed my site with the PDO error. Only fix i found was to restore to previous code and db before update.
Is there an issue with the update and the new registration state for "held" overriding existing registration states?

You can fix this by running

alter table registration_type add column default_state varchar(128) not null;

on your database.

It seems like registration runs some code in the bootstrap that assumes the update has already been run - probably loading a registration entity.

Ran into a similar issue - problem was that update.php had not been run after an update (wasn't my fault I swear). cache clears were crashing out too. Running that command above improved the situation and the update.php did fix it. Thanks much for the pointer.

#2 certainly fixed the problem.

But later I found, the default_state column is actually set to be null by default.

So, changing the code as below works without flaws,

ALTER TABLE registration_type ADD COLUMN default_state varchar(128);

Or,
if you have already added the column, you can modify by
ALTER TABLE registration_type MODIFY COLUMN default_state varchar(128);

I tried running both of the fixes in #4 (it seems the update had already added that column for me) but I continue to get the error listed above. I'm going it though the UI not through Drush. It has crashed out my site completely. I have reverted to 7.x-1.3 but am STILL getting the error. I was running the patch the "default state" column originated from = (https://www.drupal.org/node/2055145) and already had data in that column, I wonder if that has anything to do with it?

*** Revised comment: After messing around a bit, a some closer inspection, I found I am actually getting the error from the registration_state table. Opening a new issue.

As @HongPong notes this will happen only if you do not run update.php after updating to v1.4 of the Registration module.

More specifically registration_update_7106() defined in the install file here adds the "default_state" field to the "registration_type" table.

Closing as "works as designed" because update.php must be run after updating.

I'm re-opening the ticket because it's not acually possible to run update.php (or drush updatedb) after updating the module code to 7.x-1.4. Doing that produces exactly the error that @AmadeusThiemann opened this issue for.

Adding the database column manually as described in #4 does resolve the problem and allows me to run pending updates, but I don't think that's a great fix.

Would it be possible to wrap the default_state property in a conditional that checks whether the schema version for registration.module is already at 7106 and exclude it if not? That would allow people to run the update successfully without needing to first manually tweak their database.

Yup, I ran into this twice, and had to do the manual fix. I updated the module, IMMEDIATELY ran update.php, and it still broke :/

Ran into this after restoring a site I'd archived (so it was a few versions behind). Ran ALTER TABLE registration_type ADD COLUMN default_state varchar(128); from #4 and then ran updb. All is good.

I ran into this problem after upgrading from 1.2 to 1.6. This took my site down. Rolling back to 1.2 was not sufficient to get the site back online, but the fix in #4 got it back online...

ALTER TABLE registration_type ADD COLUMN default_state varchar(128);

I've not yet tried upgrading to 1.6 again and running this query. If the query is necessary, as it seems to be, it should be part of the upgrade routine in the module code.

I have now done a couple upgrades to 1.6 without running into the problem I mentioned in #10. I'm not sure, but I may have had a problem because I cleared the cache before running update.php. If there's any trouble reproducing the bug, I would try it this way...

• Update module code
• Clear the cache, either on the performance page or with drush, before running update.php

Though clearing the cache isn't something one would normally do before running update.php, doing so should probably not bring a site down.

I also ran into this problem, updating from 1.3 to 1.6 .

A minor version number update should not make your site fail to bootstrap, caches cleared or no. This is definitely critical.

@maintainer what does registration do during bootstrap that runs this query? A patch for this should be simply wrapping it in an if statement that checks the schema version.

I ran into the same problem updating from 1.4 to 1.6, altering the table as suggested on #2 and running update fixed the issue.

I had the same problem when installing via drush 7.x-2.0-beta1.
I deleted the sites/all/modules/registration directory as a way to get my environment back.

I updated from Entity Registration 7.x-1.0-beta3 to 7.x-1.6.
I ran into the same issue. The problem was that the update functions of the module's install file did not run as the schema version of the module in my db was -1. These functions add the appropriate db fields and do other db stuff too.
I manually set the schema version to 7000, so that the update functions with version numbers 7100-7107 would run and it fixed the problem.

drush sqlq "UPDATE `system` SET `schema_version` = '7000' WHERE `system`.`filename` like '%/registration/registration.module';"
drush updb

Hello,

I have the same issue when updating to Entity Registration 7.x-1.7. I didn't want to update the database manually because normally we would use a hook update, in this case update 7106; neither drush updb or update.php script worked.

So here is a patch. It fixes the above problem and allows us to update normally.