Suppose you have a CCK field that accepts multiple values, like so:

$node->field_genre = array(
  0 => array(
    'value' => 'Comedy',
  ),
  1 => array(
    'value' => 'Action',
  ),
  2 => array(
    'value' => 'Science Fiction',
  ),
);

If we set up luceneapi_cck to add this field to the index as a "keyword" field, the resulting indexed term will be the space-separated concatenation of all the values: "Comedy Action Science Fiction". If we set it up as a "text" field, it'll be tokenized and produce the following four terms: "Comedy", "Action", "Science", and "Fiction".

I don't think this is really a problem for text search, but if, for instance, you set up a facet and then enable the facet block, the terms described above are what will show up …and in that use case, it would be best if the index referred to "Comedy", "Action", and "Science Fiction", since those are the actual values stored in the node.

I'm not really sure how to go about fixing this, but I thought it'd be worth a mention to see what everyone else thought. Ideas?

CommentFileSizeAuthor
#2 multivalue.patch974 bytesjazzslider

Comments

jazzslider’s picture

Did some quick research, and if this post is accurate, it's possible to specify a single field multiple times in a single document. That would map pretty well to the concept of multivalued CCK fields, so maybe we could do that when such fields are added to the document? E.g.,

foreach ($node->field_genre as $properties) {
  luceneapi_field_add($doc, $field_type, 'field_genre', $properties['value']);
}

All theoretical without patches, of course :) I may be able to roll something together today, but I thought I'd suggest the idea first in case anyone wanted to weigh in.

Thanks!
Adam

jazzslider’s picture

StatusFileSize
new974 bytes

OK …the attached patch doesn't entirely solve the problem, but it's a better example of what I was thinking.

The thing is, when you index your content using this patch, the luceneapi_facet module only seems to expose the very last value in multivalue CCK fields …in other words, it looks like only the last value is actually being added to the index.

I'm not sure where this would need to be fixed …lots of moving parts :) But I thought I'd attach the patch anyway so you could see what I'm aiming at.

Thanks!
Adam

jazzslider’s picture

Ahh, I see what's happening. I followed the function calls down into the Zend Framework layer, and it appears that Zend_Search_Lucene_Document::addField() doesn't support this sort of multivalue stuff …if you call it multiple times, it just overrides the previously-set value in the _fields array.

I guess the link I provided earlier (and this) must only apply to Java Lucene. Kind of a shame, really …I'm going to see what I can find in the ZF issue queue; might be worth suggesting the functionality.

Thanks!
Adam

jazzslider’s picture

OK, I've added an issue for this on the ZF tracker (ZF-8551). It looks like it would require some pretty significant changes, so I'm not sure if it'll get accepted …but it's worth keeping an eye on if you're interested in this sort of functionality.

Of course, I could be misinterpreting how Apache Lucene handles this too, since I don't have an instance of it handy to test.

Thanks!
Adam

cpliakas’s picture

Category: bug » feature
Status: Active » Postponed

Hi Adam.

Thanks for forward porting this post. You are correct that the version of the ZF Components Search Lucene API is using does not support this feature. Unfortunately we have to delimit multiple values withing a single field. Changing to a feature request since the functionality does not exist yet. Postponing because it is dependent on the ZF modifying the library.

Thanks for bringing this up,
Chris

lejon’s picture

subscribe

jim kirkpatrick’s picture

For what it's worth this was a big deal for us too... Tried a bunch of things but in the end just wrote some code to convert the CCK multi-text fields into taxonomies and it all started working after using those taxo facets instead... Let me know if that code snippet would be useful.

cpliakas’s picture

Status: Postponed » Closed (won't fix)

Due to end of life announcement.