Sorry, I usually think of things in Lucene land and reflexively think of the
fat client.
Anyway, here's your problem I think...
WordDelimiterFilterFactory. See:
http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.WordDelimiterFilterFactory
It's losing the # altogether, as indica
ok, I just realized I was using the luke handler, didnt know there was
a fat client, I assume thats what you are talking about.
I downloaded the lukeall.jar, ran it, pointed to my index, found the
document in question, didn't see how it was tokenized, but I clicked
the "reconstruct & edit"
In Luke, there's a tab that will let you go to a document ID. From there
you can see all the fields in a particular document, and examine what
the actual tokens stored are. Until and unless you know what tokens
are being indexed, you simply can't know what your queries should look
like...
*Ass
Thanks Eric,
I looked more into this, but still stuck:
I have this field indexed using text_rev
I looked at the luke analysis for this field, but im unsure how to
read it.
When I query the field by the id I get:
−
5405255
###'s test blog
If I try to query even multiple ### I get n
Well, the very first thing I would is examine the field definition in
your schema file. I suspect that the tokenizers and/or
filters you're using for indexing and/or querying is doing something
to the # symbol. Most likely stripping it. If you're just searching
for the single-letter term "#", I *th
ok thanks, sorry my brain wasn't working, but even when I url encode
it, I dont get any results, is there something special I have to do
for solr?
thanks
Joel
On Dec 7, 2009, at 3:20 PM, Paul Libbrecht wrote:
Sure you have to escape it! %23
otherwise the browser considers it as a separat
Sure you have to escape it! %23
otherwise the browser considers it as a separator between the URL for
the server (on the left) and the fragment identifier (on the right)
which is not sent the server.
You might want to read about "URL-encoding", escaping with backslash
is a shell-thing, no
