Hi, I can't use Solr Views module for the moment (need to check the compatibility of all modules with views 3...), but would really like to have a text input box as filter instead of facets, because the number of terms in my taxonomy is growing.

Of course, this would be usable only if there is some autocomplete (with number of related nodes) to guide the user in the selection of the appropriate term/filter.

Any hints on how to do that ? Any plans for this module about such a feature ? Many thanks !

Comments

butler’s picture

butler commented

This is something I am also really interested in, but thus far have not been able to figure out where to even start. Any hints would be greatly appreciated:

-by what mechanism are filters created for Apache SOLR Search Integration? They don't seem to have anything to do with the Drupal filtering system which is for filtering html vs php code etc.

-how would I convert keywords entered from a search form to Apache SOLR Search Integration filters?

-having converted keywords entered from a search form to Apache SOLR Search Integration filters, would these filters automatically be included when "retain filters" is checked on the search page? Or would there be extra steps to accomplish this?

Thanks...

Amy_M’s picture

Amy_M commented

Subscribing

janusman’s picture

janusman commented

Needs #1062818: APIfy ApacheSolr Autocomplete to tackle more use cases.

janusman’s picture

janusman commented

Only certain kinds of data in Solr would work with autocomplete:

1) Only text-type fields

2) Only field types that *aren't* processed (stemmed, tokenized, etc) before storage. For instance: term names are processed/stemmed, so autocomplete suggestions would look "weird". The only way to make those work would be to change the schema and the code building the $document to index, so that those could be stored as-is (no processing). I'm not sure those modifications fit in this module's scope.

3) Only field types where the QUERY the UI sends back to Drupal+ApacheSolr module is text. For instance, filtering by taxonomy term requires a numeric tid (?filter=tid:123); Solr only returns string suggestions and does not know about what Drupal id that string was generated from.

An exception would be if we accept that an additional DB query be issued so that the numeric ids for each suggestion would be generated and then fed back into the autocomplete widget... there would be need to add database indexes to (for instance) term names so those queries would be scalable. Of course none of that would work when case (2) above applies.

So, summing up, there are only a few candidate fields left:

  • Fit above limits + existing UI in modules:
    • CCK text fields
    • sname (usernames) (only with extra DB query to get userid)
    • type_name (nodetypes) (only with extra DB query to get the nodetype machine name)
  • Can query solr for these, but there is no UI to let users query it in Drupal (meaning, there is no "Filter by X" facet block for these fields.
    • stitle (node titles)
    • ?? (Maybe some by some contrib modules?)
  • Solr schema would need changing.
    • sm_vid_[vocabulary name] (taxonomy terms). Reason: autocomplete would be case-sensitive,. Also, would require extra DB query to get term ids. Or perhaps there could be other approaches, but not in my head yet =)

So the only hard candidate is probably CCK text fields?