: i recently upgraded al systems for indexing and searching to lucene/solr 3.1,
: and unfortunatly it seems theres a lot more changes under the hood than
: there used to be.
it wounds like you are saying you had a system that wsa working fine for
you, but when you tried to upgrade it stoped working.
: i have a java based indexer and a solr based searcher, on the java end for
...
: Analyzer an = new StandardAnalyzer(Version.LUCENE_31, nostopwords);
right off the bat, that line of code couldn't posisly have been in your
existing 2.9 code (Version.LUCENE_31 didn't existing in 2.9) and
instructs StandardAnalyzer to to some very basic things very
differnetly then they were dong in 2.9...
http://lucene.apache.org/java/3_1_0/api/all/org/apache/lucene/analysis/standard/StandardAnalyzer.html
I would start by setting that to Version.LUCENE_29 to tell
StandardAnalyzer that you want the same behavior as before.
Having said all of that -- the LUCENE_31 is considered better then the
LUCENE_29 behavior, so you should consider change that to get the benefits
-- but you need to understand your full analysis stack to do that.
: and for the solr end i have:
...you should also check if you added a luceneMatchVersion/ of LUCENE_31
to your solrconfig.xml -- if not do so so it's consistent with your
external java code.
generally speaking just having your indexer using an off the shelf
analyzer while your solr instead uses something like WordDelimiterFilter
isn't going to work well, you need to think about index time analysis and
query time anslysis in conjunction with eachother.
hang on, scratch that -- you may think you are using
WordDelimiterFilterFactory, but you are not...
: fieldType name=text class=solr.TextField positionIncrementGap=100
:
: filter class=solr.WordDelimiterFilterFactory
: generateWordParts=1 generateNumberParts=1 catenateWords=1
: catenateNumbers=1 catenateAll=0 splitOnCaseChange=0/
: analyzer class=org.apache.lucene.analysis.standard.StandardAnalyzer
: ignoreCase=true /
: /fieldType
...you can't just plop a filter/ tag in a fieldType/ like htat nad
have it mean something. filter/ can be used when you are declaring an
custom analyzer chain in the schema.xml, if you use analyzer class=...
/ you get a concrete analyzer that has hardcoded behavior.
so if you aren't getting matches, it's a straight up discrepency between
the LUCENE_31 and whatever seting you have in solrconfig.xml (which if you
didn't add to your existing config, is going to be a legacy default ...
2.4 or 2.9 ... i can't remember)
-Hoss