I'm trying to use apachesolr with the CCK to index and present an added field ('author') as a facet. Looking at the code and reading the issue queue, I see this is limited to text fields that use a select widget. The issue discussions are ambiguous as to why this is - in #336157: CCK field indexing broken robertDouglass references a 'safe' fix, which apparently embeds

tags in the field, breaking facets, while elsewhere (sorry, lost the link) there was reference to the potentially large number of facets being the issue.

Which is it? Are we likely to see this feature in the future? Is there an issue with hacking it in myself that I should be aware of?

BTW, hook_apachesolr_cck_field_mappings is insufficient for text fields - it is overwritten immediately.

Comments

pwolanin’s picture

pwolanin commented

Yes, I think that hook does need work to enable proper use with a variety of CCK fields. We will disucss such refactorings and fixes next week at Drupalcon.

moshe weitzman’s picture

moshe weitzman commented

I agree that it would be useful to have these fields as optional facets. Admins can be informed about the risks of too many values.

pwolanin’s picture

pwolanin commented

We should at least un-break the APi. I"m not sure we shoudl support this in the standard module, but it should be made easy to support w/ custom code if required. For "tagging" in general we already have the taxonomy module.

moshe weitzman’s picture

moshe weitzman commented

I'm not sure what un-break the API means or how to proceed with this.

kcoop’s picture

kcoop commented

The current hook_apachesolr_cck_field_mappings allows you add fields to the map, but then the resulting merge overwrites any that use the same key (i.e. text). It would be better to create the defaults first, then pass in an array reference.

But has the bigger question (whether cck text fields that use a text field for their input are indexed) been addressed? This seems a pretty big limitation.

ceejayoz’s picture

ceejayoz commented

Subscribing.

robertdouglass’s picture

robertdouglass commented

@kcoop: I *believe* that all cck text fields get indexed. If not it is a shortcoming of this code:

// In apachesolr.module, around line 332
function apachesolr_node_to_document($nid) {

...

    // Build the node body.
    $node->build_mode = NODE_BUILD_SEARCH_INDEX;
    $node = node_build_content($node, FALSE, FALSE);
    $node->body = drupal_render($node->content);
    $node->title = apachesolr_clean_text($node->title);

    $text = $node->body;

Note that this is just rendering the node and smooshing all of its text together, so the text fields are not their own Solr index fields, but are part of the combined text field.

The current hook_apachesolr_cck_field_mappings allows you add fields to the map, but then the resulting merge overwrites any that use the same key (i.e. text). It would be better to create the defaults first, then pass in an array reference.

Yes, we need to fix this API. I just wrote an article about the API which should help people understand better about how it works: http://acquia.com/blog/understanding-apachesolr-cck-api

pwolanin’s picture

pwolanin commented

CCK text fields are indexed as part of the body. They are not indexed separately at the moment unless they are using optionwidgets.

robertdouglass’s picture

robertdouglass commented

@pwolanin - right - and if anyone observes otherwise it is a bug so they should please report it =)

pwolanin’s picture

pwolanin commented
Status: Active » Closed (duplicate)

see: http://drupal.org/node/271753