3

We need to create a field for an Index that is not going to be tokenised but still be searchable. In Azure Search if you make a field searchable, then the contents of the field are tokenised. If you make it filterable (documentation says then it wont be tokenised) then you cannot search it. In Lucene a KeywordAnalyzer does this job. Since Azure Search is also using Lucene cant understand why we cannot store a field contents AS IS in the index for searching WITHOUT splitting all the words/removing stop words etc. etc. Would appreciate any assistance

user2981411
  • 859
  • 12
  • 34

1 Answers1

1

Using keyword and other Lucene analyzers is now possible using Custom analyzers feature of Azure Search. Note: this functionality is still in preview.

HTH!

Eugene Shvets
  • 4,561
  • 13
  • 19
  • Many thanks. By the way, in Azure Search you can currently set a field both as Filterable AND Searchable. Is this not a conflicting scenario as if you make a field that contains say "Barack Obama" as filterable and then make it also searchable, the fields contents will be tokenised to "Barack" and "Obama" defeating the filterable requirement. – user2981411 Dec 16 '15 at 14:23
  • 1
    Under the hood, we inject a separate field to avoid conflicts. – Eugene Shvets Dec 16 '15 at 15:56
  • Many thanks. Now it makes sense! Instead of using a custom analyzer in the preview, is there any way for us to get hold of this additional field which I presume is the non-tokenized version of the field? – user2981411 Dec 16 '15 at 17:20
  • No, that field is an implementation detail and not exposed. – Eugene Shvets Dec 16 '15 at 17:29
  • Thanks. Before leaving the comfort of the .NET Libarary and going REST API , any idea when this feature will make it into the library? – user2981411 Dec 16 '15 at 17:34
  • Sometime in the first half of 2016, we'll introduce a preview .NET SDK that will expose preview REST API features, so the "library lag" will be much shorter. – Eugene Shvets Dec 16 '15 at 17:51