Add a way to prevent exportable rebuild on cron run

Re-using the features variable makes sense to me.

+++ b/entity.features.inc
@@ -171,8 +194,26 @@ function entity_features_export_render($module, $data, $export = NULL, $entity_t
+ * Implements hook_features_rebuild().
+ *
+ * Features component callback.
+ */
+function entity_features_rebuild($module = NULL, $entity_type) {

Problem is this is a features component callback only - so when no feature component is in rebuildable state, e.g. you have nothing exported or it's all overridden - it won't be fired.

We'd need a way to kick in independently - so we now we can rebuild when features rebuilds its stuff also. Unfortunately, features does not provide a general hook to react on feature-rebuilding yet, so I guess we'd have to add something like that.

Also, a features-rebuild drush command would make sense if rebuild on cache clear is disabled - but that's another story I guess.

Yeah, this approach looks good to me. We'd probably want to add something to the README about it, so people are aware of this option to speed up things :-)

Thanks on the great work on this patch and the features patch. I was little worried about people running features 2.0 and missing the new hook, but then I figured features_rebuild_on_flush is quite undocumented - so probably not a lot of people have it activated. I'll make sure to document this in the commit message still though.

Thus, I took your patch and committed it. README text was already good thanks, I tweaked it a little bit more though.

uhm, just realized it's not hidden at all - so this could be a problem then. Therefore I did not commit it for now. Attached is an updated patch with my README tweaks.

Let's improve it so it will continue working with features 2.0 and features_rebuild_on_flush set to TRUE also. Maybe best, let's just add an additional flag like entity_rebuild_on_flush = TRUE|FALSE and leave it to the people whether they use features for triggering rebuilds?

ops :)

Well, if we're introducing a new variable anyway - how about making it entity type specific too

Why would you disable it per entity-type? Is there a use-case you have in mind?

Will this interfere with features updates or rebuilds using drush?

drush fr feature-name
drush fu feature-name

1. +++ b/entity.features.inc
   @@ -130,6 +136,18 @@ class EntityDefaultFeaturesController {
   +    // entity_defaults_rebuild(array($this->type));
   

   That line should be removed imho, the comment is enough.

2. +++ b/entity.features.inc
   @@ -171,8 +195,32 @@ function entity_features_export_render($module, $data, $export = NULL, $entity_t
   + * Revert all defaults when a features rebuild is triggered - even the ones not
   

   Rebuild all defaults

3. +++ b/entity.module
   @@ -1076,7 +1076,10 @@ function entity_flush_caches() {
   +  // Also check if features has explicitly disabled rebuilding on cache flush.
   

   Comment needs an update - its our own setting.

4. +++ b/views/plugins/entity_views_plugin_row_entity_view.inc
   @@ -88,6 +88,7 @@ class entity_views_plugin_row_entity_view extends views_plugin_row {
        if ($entity = $this->get_value($values)) {
   +      $entity->view = $this->view;
   

   Unrelated.

+  function rebuild($module = NULL) {
+    // We don't do the rebuild here since a whole rebuild is triggered in
+    // entity_features_post_restore().
+  }

+function entity_features_rebuild($module = NULL, $entity_type) {
+  return entity_features_get_controller($entity_type)->rebuild($module);
+}

Why do we need this code if all the logic is done in entity_features_post_restore()?

#17 looks good for me. Cache clearing is way faster now.
Removed EntityDefaultFeaturesController::rebuild() as all the logic is done in entity_features_post_restore().

Thanks, this looks ready to me and can go into the next release. Let's put it on the table for others too first.

Thanks, committed.

So, now on every feature rebuild/revert, alll the entity defaults are rebuilt? That might cause a bit of a slow down for reverts -- I believe drush batches them so does a few at a time.

If you got 20 features, and only one has entity exportables, it'll do a rebuild each time any of those features are rebuilt, correct?

For example, during batched module enable during an install of a distro

That means whenever _features_restore with op == rebuild

That will slow down install of distros in that situation (not sure which distros that is/ what components are provided by entities). Probably would be better to test if the features being reverted provides an exportable provided by entities

Previously "Full" rebuild was executed on every cache clear. With this patch performance of cache clear is really increased. But @hefox is right, feature revert performance is definitely decreased.

Maybe, is there a way we can improve that during batches and skip it if we did it already during a batch? Sounds like we should create a follow-up issue.

Wondering, why is entity_rebuild_on_flush not set to FALSE by default? Are there any negative side-effects setting entity_rebuild_on_flush to FALSE?