Currently when defining the indexers, one can specify the field mappings from source to target fields. Only a limited set of functions such as Extract token at position etc are supported. It would be desirable to support Func syntax such that each row is passed onto the func which then decide the target field value based on developer defined logic in func.

Eg: we have a cosmo db source and a azure table storage data source. The partition key for cosmo db collection is combination of tenantId:studentId for efficient read/writes across partitions based on our data. The azure table storage partition key is tenant id and student id is the row key. Some business function specific details about the student are stored in table storage and are managed by different microservice that is NOT responsible for the central student service (uses cosmo db).

There is a special field 'Key' that ATS Data source provides in azure search which is PKRK combination. But as in cosmo db we have : in those we need some way to make sure the index row that is updated is same so that search on combined set of fields from multiple sources can be performed.

I believe that a good pattern for Azure Table Storage is to enable fast deletes by simply dropping tables. I've implemented a multi-tenant model for my data using a table per tenant, and would like to aggregate search data across tables.

The current recommendation is to create an indexer per table. This means the number of tenants I support (which I'm hoping to be in the thousands) is limited to the number of indexers I can create, which is a very low number.

The latest table storage SDK has methods to asynchronously list tables in a segmented fashion using continuation tokens and a search prefix. Any chance you could update the Table Storage Indexer to support wildcards at the *end* of the target table name, e.g. "*" to index every table, or "user*" to get every table beginning with "user"?

Scenario: Thanks to the power of Azure, I have setup a indexer which continuously updates my index from the Azure sql db. Now I want to know if there are any errors while processing any document and why it failed to update the index(error message). This information is very critical for new documents or any document which is modified in the prod database. Note: Different teams do not have access to the Azure search service portal.

Current state: We already have indexer execution status but this information needs to be processed by another process by polling.

Ask: If this information is automatically dumped in Application insights or atleast whenever the indexer fails to add document. This will create a seamless process from Azure sql db, azure search and application insights.

Thanks,
Ashish

For a document, where there are multiple values in its collection type column, it gives it lesser score (and hence either to come lower or may not even come in the result) to it even though the search query has matched with ONE of the values in the list COMPLETELY.

This is because, currently Azure Search considers list of all the values provided in the collection type as a single string by concatenating all of them.
My requirement is that if the search query (for that field) matches with any of the values in the collection, it should consider it as a complete match and use that specific value where it has matched more, to score the document.

Example:
My index has two fields
NameCollection - Collection(String)
XYZName - String

Document1:
NameCollection => {"Dieter Esser", "Biergarten Rodehof"}
XYZName: "Dieter Esser"

For a search query "Dieter Esser" against NameCollection should consider the above document as a complete match and would give same score as of that when the search query has matched against "XYZName" field. But in reality it gives a lesser score, and hence pushes down this document in the results, and sometimes it may not even appear in the result.

You currently can only create a service instance through an ARM template, you then need to make REST calls to create, update, or delete Data Sources, Indexes, and Indexers. This makes using Azure Search a challenge in solutions that are released in a Continuous Delivery model. If I want to use Release Management in VSTS to automate deployments, I need to write additional PowerShell scripts to call Azure Cmdlets to get the Primary Key for the service, then call REST APIs through PowerShell, and suck in JSON files to send as part of the request. It's a very complicated process to be able to automate.