Single-valued taxonomy field facets disappear after upgrading from 7.x-1.1

Have managed to replicate the issue and I have a feeling it's Apachesolr's new schema, here's what happened:

I had a large amount of taxonomy term facets that were all working perfectly fine, I was attempting to help @solquimpo solve her problem when I replicated it locally. All of my facets were saved in features and I noticed that in my panels page configuration 2 facets were missing/broken, so I went ahead and reenabled them on the facets admin page. I then noticed that they still weren't on the panels page, I then found out that they had a new component name (and therefore hash) in features, they'd gone from facetapi:apachesolr@solr:block:im_field_audience to facetapi:apachesolr@solr:block:is_field_audience which means the schema changes in the updates to apachesolr affected them some what.

Now the 2 facets don't work, all old facets still work as they are multi select taxonomy so the schema changes would not have affected them (the ones that no longer work are single select).

Can confirm that this is an issue with 7.x-1.2 schema verison (or module version?) of apachesolr. I rolled back to apachesolr-7.x-1.1 and applied the solr config under solr-3.x and did the same tests and taxonomy facets now work.

I have tested both vanilla installs and the existing site, in both cases rolling back to apachesolr-7.x-1.1, reconfiguring my solr core, and reindexing the content worked.

Hmmm...looks like an excellent get out of jail free card, but what about those of us locked in to the current version (7.x-1.3 and solr core 3.x)? Is there another way to approach this?
I have a 'har dto change' solr installation, but my data schema is still flexible.
Would it be possible to dump my taxonomy fields and then re-define/re-import data, thus recreating the data definitions inside the new schema?

Rolling back to apachesolr-7.x-1.1, clearing caches and solr index, worked to restore taxonomy facets here too.

I noticed the change from im_ to is_ for a custom filter page, some time ago. Not sure what the significance of the change is, my solr index appears to have both is_ and im_prefixed fields, but only the is_ field seems to be useful.

Thanks for the help guys, but I've jumped ship.
It seems to me that the future for solr integration is in the search_api_** family. Very nice factoring of modules, lots of forward development and active maintainers. Plus a more generic roadmap into D8 (afaict).

Changing title for better description

This looks like it was caused by code that slipped in as part of #1874420: Solr4 Entites Not Being Removed with deleteByQuery.

Here's a simple patch that fixes it for me.

By the way, you need to reindex your content after applying the above patch in order for the facets to start appearing again.

I then found out that they had a new component name (and therefore hash) in features, they'd gone from facetapi:apachesolr@solr:block:im_field_audience to facetapi:apachesolr@solr:block:is_field_audience which means the schema changes in the updates to apachesolr affected them some what.

Beats me why that changed, but it seems like a problem to me also. I would think taxonomy terms (at least those associated with a hierarchical vocabulary) should always be multiple rather than singular, so that the parents can be stored? As described in the code comments of the function I patched above, the goal is that if you have a vocabulary with terms Fruit > Apple, then a piece of content tagged with "Apple" should show up when someone searches for fruit. That's completely independent of whether the Drupal field itself is multivalued (e.g., whether "Apple" and "Fruit" or just "Apple" are stored in the database), so I would think it should always be multiple from Solr's perspective and thus the $field_info['multiple'] == true check visible in the above patch file wasn't right to begin with.

However, fixing that is not necessary to fix the main issue here; the above patch should work on its own.

Looking through this it seems to make sense. Thanks for figuring out the quirks here.

The multiple only prevents to index multiple terms in a field that is defined as single. Perhaps the logic to generate the solr field key is wrong. I remember that this multiple check is required as solr will start to bark when you index multiple values in a single valued field.

Im not 100% convinced that the patch you proposed is actually a better solution but I've been thinking how to improve it and I cannot come up with a better one.

The problem actually started with this change. There is no way we can roll that back as it is correct and we were not doing this for a long time. I will

function apachesolr_entity_fields() {
...
// Cardinality: The number of values the field can hold. Legal values
        // are any positive integer or FIELD_CARDINALITY_UNLIMITED.
        if ($row['field']['cardinality'] != 1) {
          $row['multiple'] = TRUE;
        }
...

I wonder if we should, as you suggest, make these term fields always multiple? I'm not really sure where we should put that logic then.

For reference, the patch that added this is in commit: 93bec982,
d.o issue: https://drupal.org/node/1900036
Changelog: by remimikalsen, swentel | albert78: Fixed node reference with multiple values.

Patch from #10 helps me with this issue too.
Thanks a lot !

Rolling back to apachesolr-7.x-1.1 resolved it for me as noted in #4 by acbramley.

This is a duplicate of https://drupal.org/node/1979506

The patch attached to this issue is not suitable for a hierarchical taxonomy, as it will not index the parent taxonomy terms, meaning you will not be able to use them when faceting.

Please see comment #18 which describes this issue as a duplicate and references the issue where this has been fixed.

Updated issue summary.