React properly to Field API field changes

I am running into this exact same problem with taxonomy term facets. I am seeing a random taxonomy term listed as a filter under a taxonomy facet that the term doesn't belong under. Funny thing is, that same term filter shows up under multiple taxonomy facets the that term doesn't belong under, not just one. All the term filters that should be there are not.

So far I have tried the following with no change:
- Cleared index and indexed all items
- Deleted all search/facet related items from the feature, deleted all search/facet related items, restored feature, reverted feature
- Deleted all search/facet related items from the feature, disabled and uninstalled all search/facet related modules, restored feature, reverted feature

That's right, not even uninstalling and re-installing the modules helped! I am willing to try anything if anyone has ideas. Only thing I can think of next is to remove all search/facet related items from the feature, delete all search/facet related items and build from scratch as is suggested in the original post, but this is not even a viable workaround.

I am currently using the following modules:
Current Search Blocks 7.x-1.2
Facet API 7.x-1.2
Facet API Taxonomy Sort 7.x-1.0-beta1
Features 7.x-1.0
Search API 7.x-1.4
Search facets 7.x-1.4
Search views 7.x-1.4
Search API autocomplete 7.x-1.0-beta2
Search API Solr search 7.x-1.0-rc3
Ubuntu 12.10 w/ packaged Solr v3.6.1

This is ultimately due to fields being updated in Drupal and those changes not being reflected in search indexs.

So after a long night, I finally figured out what is going on! I traced this all the way to Solr's search() function and noticed that some taxonomy fields had a different prefix than other taxonomy fields. This was ultimately due to the fact that some of these taxonomy fields were single value fields, and others were multiple value fields. In the course of building out the site, the data structure changed so that all taxonomy fields became multiple value fields. Although the fields were updated, the search index was not, and this was what was causing the issue.

Ultimately the facet value that was being returned was '1' indicating that the field was selected, as shown in the screenshot attached in the original issue report. For my case, this was showing the taxonomy term with the tid equal to 1.

I hope this helps anyone else who comes across this issues and saves them the hours of time it took me figure out what is going on.

I think the Search API module should hook into the field update and update indexes accordingly.

bump, follow

Thanks for reporting this, and thanks to jantoine for debugging it so thoroughly!
You're right, we should definitely react when a Field API field changes from single- to multi-valued. There have been numerous instances already where I just had to say “Re-save the Fields form.” (I think this should work in this case, too, by the way. Would be nice if one of you could confirm this.)

I think, what we should do is the following:
- Write a search_api_index_recalculate_fields() function which does about the same as re-saving an index's Fields form. Should take an optional array of indexes, and otherwise work on all of them. Or maybe it should take the field name, and work on all indexes containing that field (either directly or nested)? But then the gain compared to just checking everything might be negligible.
- Call this function every time a field's multiplicity changes. (Anyone got any idea which hook that would be?)
- Also call this when hook_flush_caches() is invoked. (Always nicer to have “Clear cache” as a dirty quick-fix, instead of “Re-save Fields form” which no-one would guess out of the blue.)

I can confirm that re-saving the fields form works, as that is how I was able to fix my situation.

It looks like we will want to use the hooks found in the Field CRUD API (http://api.drupal.org/api/drupal/modules%21field%21field.crud.inc/group/...). I like the idea of it finding all index's that the field is used in and "re-saving" them. We could possibly take this further for instances like when fields are deleted and such, if this is not already happening.

I also like the clear cache idea as a quick fix for existing issues as long as it would not trigger a re-index for indexes that wouldn't need it. Ultimately this could be performed one time in an update function to fix existing issues. I do not think it is necessary every time the cache is cleared as we will catch all future instances with the field hooks.

I do not think it is necessary every time the cache is cleared as we will catch all future instances with the field hooks.

Not really, no, as not all properties are fields. As entities in contrib might specify arbitrary other properties, that might also change multiplicity at some point, we cannot guarantee that. So I'd still say that this behavior would be the safer way.

I already looked through the list you linked before, and didn't find the hook I was looking for. But it seems hook_field_update_field() is exactly right, must have overlooked that somehow.
So, yes, hopefully I can whip up some patch in the next days (or, at least, weeks).

Attached is a patch that seems to work for me. I think the additional time used when the cache is cleared or a field's multiplicity is changed is small enough, since both actions don't happen that often.

Please test, so we can get this committed.

Could someone please test this patch so I can commit it? It is a bit too complex for me to commit it without someone else at least testing it.

I guess then we'll just have to hope for the best …
Committed.

Sorry, just getting around to testing this now.
This patch is explicitly tied to changes in cardinality, which solves the OP but not my issue.

In my specific case, I need search_api to respond to taxonomy term deletions as well.
Since the symptoms are the same, I had hoped the fix would be too, but apparently not.

I don't see an existing issue about updating the index when deleting terms.
Shall I create a new one or re-open this one?

This is an entirely different issue, so it doesn't belong here. However, it is basically the same problem as in #2007692: Changes in related entities don't lead to proper re-indexing, at least roughly: it is very hard to appropriately react to changes in entities only indirectly indexed in an index (a node's taxonomy terms, a node's author, a taxonomy term's vocabulary, etc.), be it just editing or deletion.
We should probably find a solution for this problem somehow, but it probably won't be easy. For now, I suggest Rules or custom code as a work-around.