Don't include time dependent configuration and state in ctools exports

Sorry about the rookie whitespace issues :) Was a vim issue.

I'm putting this back to needs work because in testing excluding read only from the ctools export configuration may not be the most reliable way to handle having one server environment (e.g. dev, staging or production) depend on the state of the index (e.g. read/write or read only).

The best way to handle this is to duplicate your original environment via the clone operation. You set that to read only and then include that in your features/ctools exportables. If you leverage the apachesolr_default_environment variable (set in "variable" not "apachesolr_environment_variable") you can write a cloud hook to switch this on db copy (if you are on Acquia managed cloud) or come up with a similar recipe if you are not.

New patch to follow.

New patch. Removing 'apachesolr_read_only" from the exclude list; otherwise same as patch in #4.

Ok so back to "needs work" :)

Now the issue is even with this patch and the fact we're excluding this configuration from the ctools export, when the module goes to set any of those variables (e.g. index last updates as in below):

mysql> select * from apachesolr_environment_variable
    -> ;
+--------------------------+--------------------------+---------------+
| env_id                   | name                     | value         |
+--------------------------+--------------------------+---------------+
| search_server_1_0 | apachesolr_index_updated | i:1367953222; |
+--------------------------+--------------------------+---------------+
1 row in set (0.00 sec)

... ctools sees this as an override. If you try to revert, your configuration never reverts because ctools doesn't know (I'm assuming) that this variable should be removed. Clearing out this table (thus removing the one variable above) and then doing a revert brings it back to default state. Didn't run into this until I tried to revert across our 20 dev sites.

What I would like to do is create some patches that move these transient variables (e.g. time dependent ones like timestamps) out of the apachesolr_environment_variable table and place in the variables table (of course making them environment specific). Thoughts?

@Steven, nice attempt there in #11 - I like that recipe. I think that takes care of altering the ctools export to try and prevent features from showing an override, but I think the override still gets applied since I see those three ephemeral fields in the database:

mysql> select * from apachesolr_environment_variable\G
*************************** 1. row ***************************
env_id: search_server_1
  name: apachesolr_index_last
 value: a:1:{s:4:"node";a:2:{s:12:"last_changed";s:10:"1389277194";s:14:"last_entity_id";s:6:"216851";}}
*************************** 2. row ***************************
env_id: search_server_1
  name: apachesolr_index_updated
 value: i:1389278702;
*************************** 3. row ***************************
env_id: search_server_1
  name: apachesolr_last_optimize
 value: i:1389242702;
3 rows in set (0.00 sec)

Since these overrides are in this database table none of the settings in code (e.g. field boosts, environment settings, etc.) are not applied. I think a true fix would involve rewriting code to not store these ephemeral values in the ctools-backed configuration.

@myselfhimself - I wish I had more time to contribute but like bleen18 said a rewrite of configuration handing is needed to correct this. We wound up removing the environments from features completely and scripting the configuration deployment. Any time this override happened with us none of our other settings were applied and this was a big issue for us to happen on ~ 26 sites.

I can explain my comment in #7 further. I actually am deprecating the patch in #7 because it still causes a feature override (read comment #8 as it has the full details). If you apply patch #7 your symptoms will be the rest of your configuration for the environment (content type bias, boosts, etc) will not get applied.

Nick_vh is definitely on the ideal path. For the interim what we did on our 20+ sites is deploy search configuration with a PHP script that we run anytime we have an environment change. The script merely extracts the serialized objects representing the configuration, unserializes the object, sets the new value, reserializes and updates the DB table. Here's an example of a field weight change we had to do across many sites (call me lazy I didn't want to manually update 20+ sites) :)

<?php

$res = db_select('apachesolr_environment_variable', 'v')
  ->fields('v', array('value'))
  ->condition('env_id', 'acquia_search_server_1', '=')
  ->condition('name', 'field_bias', '=')
  ->execute()
  ->fetch();

$config = unserialize($res->value);
$config['ts_author'] = "0.8";
$res = serialize($config);
db_update('apachesolr_environment_variable')
  ->fields(array('value' => $res))
  ->condition('env_id', 'acquia_search_server_1', '=')
  ->condition('name', 'field_bias', '=')
  ->execute();