Worked exactly as intended. The name field is now indexed as text and the
unstemmed "textgen". I have the submission throwing an OR between both for
any name searches, and voila. Stemming and wildcard searches are in tact.
Thanks!! :)
--
View this message in context:
http://old.nabble.com/Odd-w
It helps tremendously, Erick, and it was the exact idea I had last night
after reflecting with a nice scotch. :)
I'm planning on indexing the name field as "text" as I have been, and then
indexing it again as "nameLiteral" or something with a field type not
containing stemming. The code submittin
Well, the first question I'd ask is whether using the stemmers
produces results your *users* don't expect. Your original e-mail
mentions use and test cases. Can you re-visit the use case
and determine whether your users are better served by working
with the stemming? If so, then it's just a matter
If stemming is the underlying issue here, then are there any suggestions?
Would I have to remove the SnowballPorterFilterFactory from both the index
AND the query?
Just to clarify, the ability to search on "foos" and return "foo" (and
vice-versa) is quite important, but this other issue with wild
porter stemmer turns 'international' into 'intern'
On Mon, Feb 22, 2010 at 6:57 PM, cjkadakia wrote:
>
> I'm getting very odd behavior from a wildcard search.
>
> For example, when I'm searching for docs with a name containing the word
> "International" the following occur:
>
> q=name:(inte*) --
Several things:
> You're including a stemmer in your field, that'll
transform your indexed terms.
> Have you used the schema browser in the admin
page to take a look at the results of indexing with
stemming? Luke is also good for this.
> What shows up when you add "&debugQuery=true"
to your search
