You can always replace String type with Text type and KeywordAnalyzer
definition.
That keeps the whole input as one token, but still allows to modify
(e.g. normalize spaces with PatternReplaceCharFilterFactory) or even
one of the ICU filters (warning: ICU is dark magic...)
Regards,
Alex.
On
That’s correct - the original source of my data which I was crawling had
160 as space. This took a while to find. :) Solr is working fine. Thank
you !
On Tue, 20 Nov 2018 at 1:28, Shawn Heisey wrote:
> On 11/19/2018 3:31 PM, Angel Todorov wrote:
> > the *real* issue is that SOLR expects a
On 11/19/2018 3:31 PM, Angel Todorov wrote:
the *real* issue is that SOLR expects a character with a code of 160 for
space, while the standard space as typed from a keyboard has a code of 32.
Both appear exactly the same. Here's where the issue comes from. If i
generate the 160 space, and copy
the *real* issue is that SOLR expects a character with a code of 160 for
space, while the standard space as typed from a keyboard has a code of 32.
Both appear exactly the same. Here's where the issue comes from. If i
generate the 160 space, and copy paste it, it works fine for string even
like
The only thing that works is this: {!term f=MyCustomField}Some Text
Thanks
On Thu, Nov 15, 2018 at 7:13 PM Erick Erickson
wrote:
> Well, there's little likelihood that Solr will be changed this way. If
> your field were a text-based field that had a lowercase as part of
> it's analysis chain,
Well, there's little likelihood that Solr will be changed this way. If
your field were a text-based field that had a lowercase as part of
it's analysis chain, then what would you expect from searching for
"Some Text"~3? An exact match ignoring the slop? Or searching "Some
Text" (against against a
Try comparing strings char by char. White spaces are sometimes unprintable
characters.Eric.Sent from my Samsung Galaxy smartphone.
Original message From: Angel Todorov
Date: 2018-11-15 04:06 (GMT-05:00) To: solr-user@lucene.apache.org Subject:
Re: querying on field of type
hi Erik,
Thanks, but neither of those seem to work. (neither "Some\ Text" , nor
Some\ Text). Also, assuming I may have many fields with different types, I
don't think this is a very good design to leave it up to the application
developer to have different encoding based on what the underlying
No it doesn't match. You have to get the search in as a single term.
You get a lot of information by adding =true and looking at your
parsed query.
Try
myFieldName:"Some\ Text"
o
myFieldName:Some\ Text
Best,
Erick
On Wed, Nov 14, 2018 at 4:02 PM Angel Todorov wrote:
>
> Hi guys,
>
> I have
