Apache Solr API discussion

Resources

• solr-user-subscribe@lucene.apache.org

Nitpicks

• Dependency on search module
• Do we need keywords as the path? Or can they just be GET parameters?
• $params is GOOD because it is totally openly hackable
• Do we want to create a set of new classes and each handles a type of search? Subclasses of a generic class?
• Do we need to replace or rewrite the PHP library?
• Is there a way to add facets without a custom module
• Facets tend to just be displayed as lists.
• Module doesn't support multiple types of searches or saved searches. Define a framing query and search within it.
• the result set theming is very limited by use of search module.

Thoughts

• multiple documents from one node

coming soon

• Views 3
• OR facets
• JS library from Logan
• biblio module integration

Damien Tournoud

Talking points for the Apache solr BoF:

• Apachesolr 2.x: we really need to refactor most of the module, especially the Apachesolr Query object, which seems to be always getting in my way. Just see what we had to do in project_solr to do it (http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project/solr/)
  - Also, the split between apachesolr.module and apachesolr_search.module needs to be rethinked
• Support for localsolr in Apachesolr itself: I would love to have that out of the box. Except that it is using miles (who still use miles today, that's so 20th century?), it is a remarkable piece of software.
• Apachesolr Views: I think this needs to be a primary objective. It's so awesome, but not really well maintained, and the architecture issues of the parent module (especially the query object) makes its job difficult
• Multilanguage support: this is tricky, and there are several ways of doing that (separate cores with language-based routing, separate fields with fieldcopy, etc.). I would love if we could come with a standard solution.