Improve error handling

Did you run update.php right after you upgraded the module (and especially before you cleared the cache)? The latest update renamed the "{search_api_index}.entity_type" row to ""{search_api_index}.item_type", which doesn't seem to be found.

The problem hasn't got anything to do with being unable to connect to MySQL. I wondered myself why it would throw an additional exception, though – no idea.

Anyways, you probably cannot access update.php now anymore, right? (Seems to me a bit stupid to do such a full bootstrap there, don't even know what triggers the error there …)
Therefore, you have to fix this manually, by either:
- Reverting the code again to before 8552f6c, accessing the site so the cache gets filled again, then updating and running update.php
- Changing the table column yourself

I was attempting to update my website and thought it would be nice to have translation enabled. I went into the control panel of Drupal and enabled the two check boxes to enable translation, or so I thought. After saving, I can no longer access Drupal from url, receiving instead the following:
Original

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'glenmea1_drp2.dr_languages' doesn't exist: SELECT * FROM {languages} ORDER BY weight ASC, name ASC; Array ( ) in language_list() (line 2443 of /home2/glenmea1/public_html/includes/bootstrap.inc).
Additional

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'glenmea1_drp2.dr_locales_source' doesn't exist: SELECT lid, location FROM {locales_source} WHERE source = :source AND textgroup = 'default'; Array ( [:source] => An AJAX HTTP error occurred. ) in _locale_parse_js_file() (line 1326 of /home2/glenmea1/public_html/includes/locale.inc).

I went into the hosts control panel and found the two entries in the MySQL database and set them to 0. That did not fix the problem and I don't know what other options I have. HELP!

The website is http://glenmeadows.us and is hosted on Bluehost.

As far as I see, this has nothing to do with the Search API module? Please either create a new "support request" issue in the Drupal issue queue, or search/ask for a solution in the forums.

Following this update I now receive only the error:

SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1102 of /var/www/kag/sites/all/modules/search_api/search_api.module)

I ran update.php as soon as I updated the module and did not clear the cache.
It successfully renamed the field (which contains a single row for a DB server index - with 'node' as the value of item_type).

Hm … Maybe try clearing the cache now (although update.php should normally do this for you)? It seems like it doesn't find the data source controller class.
Otherwise, you could debug search_api_get_datasource_controller() a bit, and especially see what class_exists($info['datasource controller']) returns (and whether the value of $info['datasource controller'] is correct, i.e., SearchApiEntityDataSourceController).

Oh I forgot about this. I was playing with some test data and ended up scrapping it - I haven't since been able to reproduce it.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.item_type' in 'field list': SELECT base.id AS id, base.name AS name, base.machine_name AS machine_name, base.description AS description, base.server AS server, base.item_type AS item_type, base.options AS options, base.enabled AS enabled, base.read_only AS read_only, base.status AS status, base.module AS module FROM {search_api_index} base; Array ( ) in EntityAPIController->query() (line 152 of /home2/spicmac1/public_html/demo/sites/all/modules/entity/includes/entity.controller.inc).

with latest dev and stable version.

For me running the update.php fixed the problem. Thanks drunken monkey

But in my case I am redirected to a page with this error only, even when I am go to example.com/update.php

Try manually renaming the DB column from entity_type to item_type.

And don't post to closed issues – without re-opening, no-one will usually see that.

Im getting this when staging an upgrade for a client from 2.1 to 2.3

WD mailchimp_list: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.entity_type' in    [error]
'field list': SELECT base.id AS id, base.name AS name, base.machine_name AS machine_name, base.description AS
description, base.server AS server, base.entity_type AS entity_type, base.options AS options, base.enabled AS
enabled, base.read_only AS read_only, base.status AS status, base.module AS module
FROM 
{search_api_index} base
WHERE  (base.enabled = :db_condition_placeholder_0) AND (base.item_type = :db_condition_placeholder_1) AND
(base.read_only = :db_condition_placeholder_2) ; Array
(
    [:db_condition_placeholder_0] => 1
    [:db_condition_placeholder_1] => mailchimp_list
    [:db_condition_placeholder_2] => 0
)
 in EntityAPIController->query() (line 152 of
/var/www/annashae-production/sites/all/modules/entity/includes/entity.controller.inc).

Note that this occured while running 'drush up', in which the drupal core major version was upgraded as well, from 7.8 to 7.10. It occurred while running the updatedb part of drush up (fyi, drush up is equivalent to drush upc and drush updatedb in series). Thats all pretty obvious, but I'm just trying to be thorough!

I will try these things:

- running update.php again
- renaming the table column

I would prefer to not have to do something as risky as the latter on a production site. Is there a patch forthcoming for this? I can have one of our devs post something today if so..

Looks like this is a bit more complicated than i thought...

I dug into that error message more and noticed that search_api got into the mix (it was upgraded in this drush up deal as well).

In search_api.install, I noticed that they are declaring a column that, as well, is called item_type....

Hmmm...

I will try running updates for both modules seperately, and see what happens.

I may be reporting this issue in the wrong place, probably need to open a new ticket... with both modules?

Ok, just tried updating mailchimp on its own, then running the rest of the updates, and it went fine. Funny thing is that, this time around, it only ran update 7200 and not even 7201. Also - no sign of either column in the mailchimp_lists table - was it renamed to list_type?

Anyways, I will leave it up to the maintainers to close this if they feel things are o.k. Should I report this to the search API folks? In fact... arent you involved in that as well drunken monkey?

Arg. Now its trying to run both 7201 and 7200, and only completing 7200... but its not throwing an error when it doesn't complete 7201.

Now I just ran it in update.php, and it give me some more detail. It failed on 7201:
Failed: DatabaseSchemaObjectExistsException: Cannot add field <em class="placeholder">mailchimp_lists</em>.<em class="placeholder">name</em>: field already exists. in DatabaseSchema_mysql->addField() (line 323 of /var/www/annashae-production/includes/database/mysql/schema.inc).

So it looks like it was likely successful the first time around, but it doesn't think it is? What more information can I provide here?

I think you are in the wrong issue here?

I got this error too...
Changing the column name manually worked.

I believe the problem occurs because update.php blocks us. I wanted to run updates after updating the search_api module but was blocked because I first have to update my old facets. I'm guessing that this means the updates for search_api are not run. When I tried to install facetapi I got the error message. This would be expected behaviour if search_api couldn't run it's DB updates.

I have no reason to believe that this is related to the Search API module but didn't know where else to post. I have not performed any updates. I have been working on a new install to test upgrades. Everything was installed in a subdirectory and I finally figured out that I needed to change the base_path in .httaccess to get the test site working. I made this change and ran update.php on the new test site. Executing update.php flipped me back to my root site (production application) with this error. I do not have a clue how to fix. The new test directory (different db) is giving the same error. The production site has been up and running fine for months.

Additional uncaught exception thrown while handling exception.

Original

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.access_exposed' 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.access_exposed AS access_exposed, base.data AS data FROM {rules_config} base WHERE (base.plugin = :db_condition_placeholder_0) AND (base.active = :db_condition_placeholder_1) ; Array ( [:db_condition_placeholder_0] => reaction rule [:db_condition_placeholder_1] => 1 ) in EntityAPIController->query() (line 152 of /home1/efficie7/public_html/sites/all/modules/entity/includes/entity.controller.inc).

@all:
Theses issues because you are update code of the rule module to the 7.x-2.x but you didn't runing update database.
Please make sure you are update your database by running update.php or update using drush.

I am having the same problem as well. However, I cannot run update.php. site/update.php appears correctly, but this error pops up in the middle of the process, so update.php never completes. Thoughts?

Please post your issues details here.

Have you read #21??

It's a simple chicken and egg problem. Can't run updates until something else is resolved. Can resolve what ever it is (module install/update etc.) because the updates can't be run.

Not the use of "can't be run". A manual fix solves the problem. This means the code is stuffed.

Current D7.15 (multilanguage, PHP 5.4.4) and Updates of modules
- Search API 7.x-1.0+2-dev to 7.x-1.2
- Search API Solr search 7.x-1.0-rc1+6-dev to 7.x-1.0-rc2

show this errors:

Additional uncaught exception thrown while handling exception.
Original

SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1319 of /Applications/MAMP/htdocs/100_Projects/relevantiveIntranet/sites/default/modules/search-modules/search_api/search_api.module).
Additional

SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1319 of /Applications/MAMP/htdocs/100_Projects/relevantiveIntranet/sites/default/modules/search-modules/search_api/search_api.module).

I am currently working on improving the general error handling of the Search API, reviewing the code for any potential problems, etc. Does anyone still have any problems with uncaught exceptions or the like with recent versions of the Search API?

I have now done a (heavily IDE-assisted) review of where in the Search API (and related modules) we could have uncaught exceptions lurking. I've created issues for the related modules (see the child issues of this one), but the biggest patch is of course in this module itself. Especially the SearchApiIndex::server() could cause a lot of problems: it is rather unlikely that an index will ever have an inexistent server set, but when it does it causes havoc. The same is true if an index has an unknown item type – exceptions everywhere. In the attached patch, I've tried to fix most of those, and also to document better where exceptions could be thrown and where not. (Generally, they should never be thrown out of hook implementations.)

The patch has to be applied on top of #2130819-17: UI improvements for the "View" tabs (to avoid having to re-roll for that later) – so setting to "Needs work" for now.

One note, also relevant for the related modules: I have left some of the more severe exceptions uncaught in the admin UI – I think there we can show the admin that something is seriously wrong. They are, however, of course caught when editing the index, so the problem can be fixed.

Since I just committed #2130819: UI improvements for the "View" tabs, the test bot should now be able to test this.

Spotted another two errors: a potential "Division by Zero" error in theme_search_api_index() (when there are no items), and _search_api_get_items_on_server() should not just return 0 when an exception occurs.

Committed.

Spent some time on this with no luck.

Using core 7.26, Search api 7.x-1.0

Just added a field to a search index (named 'content_index'), cleared indexed data, clicked 'index now' and get error: 'Couldn't index items. Check the logs for details.'

Log messages:

SearchApiException: Could not index items since important pending server tasks could not be performed. in search_api_index_specific_items() (line 1481 of [path]/sites/all/modules/contrib/search_api/search_api.module).

and

SearchApiException while updating the fields of index content_index on server mysql: Cannot add field search_api_db_content_index_title.word: field already exists. in SearchApiDbService->fieldsUpdated() (line 515 of [path]/web/sites/all/modules/contrib/search_api_db/service.inc).

Didn't happen following the same steps on my offline development copy (macbook).

Thanks in advance.

Same problem as #34. Did you ever figure out how to fix the problem? Maybe this should be a separate issue?

I ended up having to delete and rebuild my search index from the ground up in order to fix the problem. Seems like there might be an issue with database tables not being removed when the fields for a search index are changed. Just a guess.