Feature revert does not work

Did you use the same version of Search API (and maybe other relevant modules) for creating the features as you are using now? Otherwise, if there were DB updates in between, the exports will of course be invalid now.

Otherwise I'll need more details on what goes wrong.

Yeah I don't think the revert actually works the way you'd expect it to. I just ran it and it delete the solr search indexes. I guess I was expecting it to be a little less destructive since I'd just done a features update it should have been exactly in sync.

The exportable system is based on the Entity API, so any questions or complaints should probably be directed there. I just implemented what was needed in the Search API and don't really understand the whole system myself.
If it turns out I'm doing something wrong, give me details and we can talk about it. But, as said, first check with Entity API whether they aren't by design.

I am having a very similar issue. I also update my index and reverted it with features. Now I am getting this errer when trying to do run cron or delete a commerce product:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'staging.search_api_db_product_sku' doesn't exist: TRUNCATE {search_api_db_product_sku} ; Array ( ) in SearchApiDbService->deleteItems() (line 555 of /sites/all/modules/search_api_db/service.inc).

So, is this a Entity API issue?

I don't have any pending DB updates.

Hey,
So the issue here is that when you do a features revert it reverts the index first and then the server, which breaks the index.
e.g:
drush fr -y --force myfeature

Do you really want to revert search_api_index? (y/n): y
Reverted search_api_index.                                                               [ok]
Do you really want to revert search_api_server? (y/n): y
Reverted search_api_server.                                                              [ok]

results in broken search index
drush sapi-i

Indexing a maximum number of 1 items (50 items per batch run) for the index Default node [ok]
index.
WD search_api_db: SQLSTATE[42S02]: Base table or view not found: 1146 Table              [warning]
'drupal.search_api_db_node_index_type_1' doesn't exist

however if I then follow that up with:
drush fr -y --force myfeature.search_api_index

Do you really want to revert search_api_index? (y/n): y
Reverted search_api_index.                                                               [ok]

I get a fixed search index! horrah!
drush sapi-i

Successfully indexed 4 items.                                                            [success]
 Id  Index               % Complete  Indexed  Total
 4   Default node index  100%        4        4

short term until someone provides a more sensible fix you can either:

• change the order of your info file to read:
  

  features[search_api_server][] = my_server
  features[search_api_index][] = my_index
  

  but beware that obviously next time you feature update it'll go back to alphabetical order

• run drush fr -y --force myfeature.search_api_index after every feature revert
• split the search_api_server and search_api_index into two features that are alphabetically named as such that they'll run in the right order

I can't see a way in features to reorder or mark dependencies or manipulate the order so this looks to be the best option of workarounds for now unless someone wants to change the search exportable stuff to name the two parts in a alphabetical order that works with the code.

That took quite a while to pick apart by the way :)
Cheers
Chris

Is it possible that this was also fixed with #1414078-24: Revert of exportables not working?
Or, generally, that this is the same problem?

Its fixed in that in terms of that its an alternative work around, but I'd argue that the solutions I proposed above are more valid since its a correct cycle to run the stuff to remove tables or anything else that a api_server has set to run on an uninstall that happens when doing a feature revert.
but yes it would appear to be an alternative take on the same problem

Still facing this issue and have found a perfectly working workaround.

Add install file for the feature and lock the server component

/**
 * Implements hook_install()
 */
function FEATURE_NAME_install() {
  // locking search_api_server to stop running into base table or view not found issue
  features_feature_lock('FEATURE_NAME', 'search_api_server');
}

It is definitely a workaround and not a solution, but a working workaround.

Also having problems with functionality disappearing and breaking that was exported using Features :-\

I'm having this issue too.

I've created a Search API server and index for nodes. Then, I exported them both to a feature and reset my site to test for a local deployment. The features get reverted in a fra --force -y and no errors appear, but the server and index still aren't created. Clearing caches doesn't work and I've checked the DB tables and they just don't exist. I'm using the Search API Database Search module for the service class. Any thoughts?

So far I've tried suggestions in #6 but none worked for me.

Modules:

• Search API - 7.x.26
• Search API Database Search - 7.x-1.7

I found a solution to the features revert not working for servers and indexes. I set up my server and index as per usual in the Search API, exported them to a feature and copied the generated configuration into a hook_install() function in my features' .install file. Now, when I reinstall the module, both the server and index are created and then I just need to revert features and the actual configuration required is reverted properly.

For example:

function mymodule_install() {

  try {
    $serverConfig = [
      "name" => "My Server",
      "machine_name" => "myserver",
      "description" => "",
      "class" => "search_api_db_service",
      "options" => [
        "database" => "default:default",
        "min_chars" => "2",
        "partial_matches" => 1
      ],
      "enabled" => "1"
    ];
  
    $serverID = (int) search_api_server_insert($serverConfig);
    if (!$serverID) {
      drupal_set_message("Could not create Search server", 'error');
      throw new Exception("Could not create Search server");
    }

    // Create a blank server index
    $indexConfig = [
      "name" => "Nodes index",
      "machine_name" => "nodes_index",
      "description" => null,
      "server" => "myserver",
      "item_type" => "node",
      "options" => [],
      "enabled" => "1",
      "read_only" => "0"
    ];

    $indexID = (int) search_api_index_insert($indexConfig); 
    if (!$indexID) {
      drupal_set_message("Could not create Search index", 'error');
      throw new Exception("Could not create Search index");
    }
  }
  catch (Exception $e) {
  }
}

I had similar issue ... and i think the issue it was by using the same machine name for both index and server

Another issue it was by not renaming the server machine name in the index "definition" ....

I hope it helps somebody ... if it's the case