Right now we only have Owner, Contributor and Reader roles for Azure Search, but reader doesn't allow you to access query keys for example. I would really like it if we have a data-reader, writer and owner role like we have on Storage accounts for example where we can give users access through Azure RBAC to read index data, manipulate data and manipulate schemas (including dropping and creating indexes).

These roles would not be able to scale the Search Service or Delete it, or do anything that would have impact on the Azure resource costs.

As described here:

https://lucene.apache.org/solr/guide/66/the-standard-query-parser.html#TheStandardQueryParser-ConstantScorewith

So if you search for:

"my term"^=1.0

The score is going to be either 1.0 or 0.

We would like to implement UI to be more transparent to users about the tag which the search term matched on. This is important to avoid PR risks with inferences on content and search term with fuzzy search.

Currently, to enable this scenario, we would need to do a lot more processing that Azure Search is already doing. Additionally, ours solution would not be as intelligent and prone to error.

Requesting the ability for Azure Search to also return the matched tag with the asset.

there is some integration of Power BI and Cognitive Services already: https://docs.microsoft.com/en-us/azure/cognitive-services/Text-Analytics/Tutorials/tutorial-power-bi-key-phrases. looking to extend this further. there are A TON of use cases for better text search / cog search in Power BI

Hi,

I would like to create index so that I will be able to search on csv/non-csv blob content. For csv blob the content is coming as empty always. Can anyone help.

https://docs.microsoft.com/en-us/azure/search/cognitive-search-skill-custom-entity-lookup#skill-parameters

Now supported: da, de, en, es, fi, fr, it, ko, pt

I want 'ja'.

It appears the Configuration dictonary for IndexingParameters only has get; and can't be set. I need this so that I can programmatically configure my new indexer to have "parsingMode" set to "jsonLines"

Dear Team,

Please introduce a 'minimum should match' parameter in Azure Search REST API (Lucene docs: https://lucene.apache.org/solr/851/solr-core/org/apache/solr/util/doc-files/min-should-match.html and Elasticsearch docs: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-minimum-should-match.html#query-dsl-minimum-should-match )

This is a user suggestion to allow for metadata that disappeared from the original document to be also removed from the indexed document:
[Azure Search] Remove field value from index when not present in data source · Issue #6761 · Azure/azure-sdk-for-net (github.com)
https://github.com/Azure/azure-sdk-for-net/issues/6761

Currently we always do updates in mergeOrUpload mode:
Add, Update or Delete Documents (Azure Cognitive Search REST API) | Microsoft Docs

https://docs.microsoft.com/en-us/rest/api/searchservice/addupdate-or-delete-documents

Hi there,

It would be important to have a way to use calculated fields that we could use basic functions to it and also use existing fields' values to calculate the value of the new field. So, we could reside the logic at the index level, instead of the code + SDK and import clients.

Thank you

ختراق فيس بوك

Add natural language capability to azure search so that from the query string search service itself can identify any filters or sort is mentioned in it. Similar service is available in Power BI Q&A.

Eg: Show me top 10 results regarding Microsoft.

All the other limits are per second - why such a low limit? We are indexing many documents at once and keep hitting it.

I frequently delete and re-create an account with the same name for dev testing purposes. I have noticed that the wait time keeps increasing after each cycle. Are you cleaning old metadata properly? I often end up waiting 45 mins to an hour for a search account to be created. (Using a Basic configuration in Central US) Please check that using an account name that has been used before does not cause long wait times.

While testing some searches I found that searching the word mine doesn't return any results.
This probably applies to other english words as well, I found this one by chance.
Calling the Analyze API with:
{

analyzer: en.microsoft,

text: mine dog test

}

Returns:

tokens: [

    {

        token: dog,

        startOffset: 5,

        endOffset: 8,

        position: 1

    },

    {

        token: test,

        startOffset: 9,

        endOffset: 13,

        position: 2

    }

]

Using en.lucene analyzer returns all 3 tokens correctly.

Why is there field count limits? Lucene itself doesn't impose field count limits. 100 on the basic plan is very small especially considering that once you use blob storage indexing it consume about 10% of your field counts.

I've developed a product to have Umbraco CMS based indexes hosted in Azure Search but it's problematic due to the field count limits since 100 is very easily reached. Even 1000 doesn't seem to need to exist. Things like Elastic and Solr have this configurable and not a hard limit.

Hello,
I have a use case to index collection (list) data into azure search index. I am using azure data factory to load data into azure search index. But it seems azure data factory copy activity does not support copy of String Array data type. The support is only available with primitive data types. Could you please add this functionality as many real life use cases have array/list in the data set.

Currently it is not possible to create a data source within a storage account in the same region as the search service if both resources have the firewall settings enabled. Only recommendation from support currently is to have the resources in different regions and use the external IP address for each in the allowed list of IP addresses of the relevant resource (though yet to get this working too!)