Smart search index with "-" character in conrtent

I think you need to escape in your search condition i.e. it should be something like +_content: (PPG1149\-6). The "-" or prohibit operator excludes documents that contain the term after the "-" symbol. Lucene supports escaping special characters that are part of the query syntax. The current list special characters are: + - && || ! ( ) { } [ ] ^ " ~ * ? : \ / To escape these character use the \ before the character.

Hi @Peter Mogilnitski,

Thank for your suggestion but I used Luke tool and find out that the hyphen wasn't indexed. "PPG1149-6" isn't consider as a word because there is hyphen there, so the analyzer consider it is 2 words. I think I need to create my own analyzer to satisfy this case.

Now, I did some workaround, I break keyword "PPG1149-6" into 2 words: ["PPG1149", "6"], then ask search engine search all documents contain both of them in any order (+_content:PPG1149 + _content:6). After that, I used TreeProvider to query in DB the expected result.

Thank @Trevor Fayas, you are correct

I disagree, I just did a simple test. Here is my config. You don`t need to do anything special. Look at my screen shots. Test your string in your index search preview if it works there, then there is an issue with your lucene query not with an analyzer. No need for anything custom.

@Peter, the search he is trying to pull the document is "1149-6" which isn't indexed. I did the same test as you, and yes searching by "PPG1149-6" works because it parses that as searching for PPG, which is part of the indexed content.

In a test of a page that contains "PPG1149-6", this is the content saved using a Simple index:

test test test search test 
test test ppg

As you can see, it cut off the numbers. You can view this in Luke lucene index toolbox by clicking "reconstruct & Edit" on the document in the documents tab.

However, i will say this does raise one valid point, you can use the Analyzer of type "Whitespace" which only uses whitespace, this resulted in the full PPG1149-6 being parsed into the document, but because it wasn't tokenized into "PPG" and "1149-6" it still won't allow it to be searched by just "1149-6". Subset gets closer, but still won't contain 1149-6, just 1149.

I think in order to fully accomplish this, he will still need to do a custom analyzer, but along with it he may have to add logic to find the code (PPG1149-6) and split it up into PPG, PPG1149-6, and 1149-6 so he can search for it.