I have a index with person data. One property of it is a skills field that is a collection of strings. Search through that works just fine. For example
search=azure&$select=skills then you get all people that have Azure in their document and it shows the skills collection for each result.
However, when you want to get all possible skills by doing the query
search=*&$select=skills
then you do get all people, but almost all the skills fields are empty (except one for no apparent reason). What I want is to be able to only retrieve the skills field values of all users. But the query doenst work like that, which I believe is a bug.

We use Sitecore CMS which now supports Azure Search indexes. During our implementation we have discovered that re-index process fails. Using Fiddler we found the Azure Search REST requests that returned 207 (Multi status) responses and then reviewed the response body to determine the errors.

Beyond Fiddler running as a proxy and capturing the HTTPS traffic from Sitecore - we found no other way to get insight into the requests/responses from Azure Search service.

We enabled Operation Log monitoring but the Operation Log monitoring does not provide details about request body and response body.

We looked into Search Traffic Analytics, but that requires application to support it.

So we are requesting a solution that would allow us to capture Azure Search requests and responses outside of application that uses the Azure Search.

Thank you,
Alex

From the tests I made, currently a single blob indexer in S2 with 1 partition and 1 replica is only able to process between 50 000 and 75 000 small office documents (1 to 4 pages) in a 24 hour period.

The current solution which would be to restructure millions of blobs into "directories" with max 75 000 blobs in them and have 12 indexers is completely out of the question due to the insane pricing model and the time it would take to both, modify consumers with new paths and move blobs to a new structure. The latter being very slow as well.

So if I want to index 5 million documents into a 1200$ / month tier which can support 60 000 000 and 100 gigabytes, I would have to upgrade to a ~12 000$ / month tier with 12 indexers and somehow figure out a way to restructure all my blobs to fit the 12 directories model... Even then it would take weeks to complete... how is that even considered by Microsoft?

At least have a way to price indexer throughput (or how many indexers we can have) without having to scale out partitions.

Azure Search indexer base64decode method should handle standard URL Safe Base64 encoded strings, and not the out-of-standard strings returned by classic System.Web.HttpServerUtility.UrlTokenEncode method, which is not even available in latest versions of the framework. This method is returning non-standard strings, as it replaces padding characters '=' with a digit indicating the number of = signs that were removed. Azure Search base64 decode method expects this non-standard strings, rather than standard URL safe Base64 encoded strings, otherwise it breaks with error: "Error applying mapping function 'base64Decode' to field 'aaa': Array cannot be null.\r\nParameter name: bytes". Which means that using JavaScript or other programming languages (for example Python base64.urlsafe_b64encode) to generate standard strings is not sufficient. We really need to add this magic digit, relict of the past.

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.