Text field values not mapped in field_apachesolr_field_mappings()

This is expected behavior because text processing takes a very long time and this would not be optimal for most of the installs

An easy code snippet solves this for your site :

/*
 * Implements hook_apachesolr_field_mappings_alter().
 */
function MYMODULE_apachesolr_field_mappings_alter(&$mappings) {
  $mappings['text'] = array(
    'indexing_callback' => 'apachesolr_fields_default_indexing_callback',
    'map callback' => '',
    'index_type' => 'string', // Do not set these to text because a facet and text processing do not make sense
    'facets' => TRUE,
    'facet missing allowed' => TRUE,
    'dependency plugins' => array('bundle', 'role'),
    'hierarchy callback' => FALSE,
    'name_callback' => '',
    'facet mincount allowed' => FALSE,
    // Field API allows any field to be multi-valued.
    // If we set this to false we are able to sort
    'multiple' => FALSE,
  );
}

It makes no sense to not have mapping for basic text fields. Keeping it out means unnecessary complexity and duplication of effort.

I'm having some problems with the fix Darren Oh has provided above.
Adding these changes did mean the text fields are indexed (I can see them in the search index report, listed with index type "string").
However, they don't appear as Facets within the facet settings.
Do I need to do anything else to make them appear as facets other than set facets to true as above?
Any help would be really appreciated.

All fixed. It's a very large data-set, they came through automatically after a couple of minutes.

Text fields should not be mapped and certainly not be used for facets. The reason for this is due to the inner workings of solr. You should map the fields as if they were strings, not text.

Strings (ss_*)
Literal representations of values, for example balloons=balloons

text (ts_*)
Parsed representations of values that go through analyzers. eg. (query) balloons = balloon.

If you map them, map them to strings, and if you want text analysis, be sure to know the implications before you map them to text fields. But, if we do this automatically, such as the patch implies, we risk getting massive strings. You surely don't want a text blob of 300+ characters to be a literal string that you facet on?

I think we need to find a more pragmatic solution here instead of mapping all text fields as strings.

My patch only affects the text field type, which is limited to 255 characters. It makes it possible to index the text field type, but does not automatically do so. People will still need to enable indexing for the specific fields they wish to use as facets. It is reasonable to expect that people will index specific fields because they really want to.

Just FYI,

Search API allows you to index text fields by default, and facets work like a charm. Fulltext fields does not work, but this is coherent with this post.

After much thinking this actually makes sense and if we can restrict it to that small text field setting it seems like a reasonable feature request and as such I will add it to the dev version.

We should port this to 6.x-3.x. Committed for 7.x-1.x

From my point of view that's already implemented in 6.x-3.x in combination with content.module:

/**
 * Implements hook_apachesolr_field_mappings() on behalf of content module.
 */
function content_apachesolr_field_mappings() {
  $mappings = array(
    // ...
    'text' => array(
      'indexing_callback' => 'apachesolr_index_content_text_indexing_callback',
      'index_type' => 'string',
      'facets' => TRUE,
      'query types' => array('term'),
      'query type' => 'term',
      'facet mincount allowed' => TRUE,
    ),
    // ...
  );
  return $mappings;
}

But in opposite to 7.x-1.x the text is not handled by apachesolr_clean_text(). I attached a patch to do that.