Closed (won't fix)
Project:
Apache Solr Search
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 Jan 2012 at 11:37 UTC
Updated:
21 Mar 2013 at 15:08 UTC
Jump to comment: Most recent file
Comments
Comment #1
nick_vhPlease upload a valid patch file?
Total crap?
I can't make any sense from this patch file :-)
Comment #2
shenzhuxi commentedI copy the lines from Solr example and didn't realize the crap. Just delete them.
Comment #3
nick_vhWell, please hand us a patch in the correct format. That would be useful for everyone
Comment #4
shenzhuxi commentedPlease check this one.
I forget to mention that I also add codes in Drupal_Apache_Solr_Service.php
Comment #5
nick_vhI'm not so sure if we'd want to enable this for everyone. The apachesolr service class is extendable so it would/could be very easy to take that class and extend it to your likings and use the modified class in your custom module.
Regarding the solrconfig/schema it might be better to maintain one extra in your own module but I will discuss this with the other maintainers!
Comment #6
shenzhuxi commentedIf extending apachesolr service class is the way to use Sole flexibly, the api in apachesolr module which is based on this class seems to be unnecessary.
I'm thinking a stack like this:
1. Solr (handle all the computing extensive tasks. Functions like load balance and distributed index shouldn't give to PHP)
2. PHP-Solr connector (I think it should be Independent from Drupal, and can be used and maintained for all php projects. http://www.solarium-project.org/ seems to be the most well design connector between php and solr (existing and active maintained but may be too big).)
3. apachesolr entity api (a module provides interface for connection and control Solr instances and doesn't provide any solrconfig/schema specific API and MAYBE deson't provide solrconfig/schema at all.))
4. node search, user search, file search (modules for all kinds of entities)
Comment #7
pwolanin commentedno, this is basically a "won't fix"
The config we fix is not supposed to be all-encompassing. Rather it's supposed to enable the features needed by the module.
The apachesolr_attachments module for example has a patch to enable the extracting handler I think. I general, if you are diving into these sort of features, you are capable of customizing your config.
Comment #8
shenzhuxi commentedWill file field in node not be indexable in Apachesolr forever?
Comment #9
nick_vhOf course it will, but it should be maintained in a contrib module as pwolanin explains. Unfortunately there is no easy way of adding extra requesthandlers yet when we use solr's rest API but I hope this happens one day, so we can provide our schema from within the module and let contrib modules alter it!
Comment #10
shenzhuxi commentedhave been added to solrconfig.xml already.
Do you mind to add one more line?
<lib dir="../../dist/" />It will make
<requestHandler name="/update/extract" startup="lazy" class="solr.extraction.ExtractingRequestHandler" >working correctly.
Comment #11
pwolanin commentedNo, I don't think that's correct. dist is not a library directory.
Comment #12
shenzhuxi commentedBut apache-solr-cell was put under dist.
http://wiki.apache.org/solr/ExtractingRequestHandler