Currently, highlighting is supported only with search, term, compound, and span operators, and this is documented in the highlighting documentation. Therefore, if highlighting is used with the autocomplete operator, then it results in an error like this:

"Highlights can not be generated. Path: "####" is not stored statically or dynamically indexed."

This is a feature request to add support for highlighting with the autocomplete operator.

For Atlas Search, I'd like to see data about what queries are run, and how many results are returned for a given query.

Today, Atlas Search runs on all nodes of your cluster. I would like to limit the nodes that queries run on so I can isolate my transactional workload from my search workload.

Elastic allows you to do to function scores, which allow us flexibility in manipulating results during certain queries. is this coming to Atlas Search?

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html

Currently, UUID is not one of the supported datatypes for Atlas Search. This is a feature request to add support for UUID datatypes in Atlas Search.

I renamed the first index I created when testing out the feature so it wasn't default, and spent quite a bit of time debugging why my queries were returning no documents. As it turns out it the default index that it queries if not defined is "default", but that index didn't exist. Instead of throwing an error about querying a non-existent index, it just returned an empty array which was very frustrating

We need support for Soundex or phonetic filters for our use cases so we can support searches for similar sounding terms. thank you!

Customer is asking about adding new Analyzers language for Polish , Slovenian, Slovak and Croatian .

Currently it is not possible to create an Atlas Search index on a not existing collection, this makes more complicated to automatise the index creation on new clusters (e.g. via terraform).

Would be nice to allow the implicit collection creation when creating an Atlas Search Index.

Right now you can only test simple queries in the Search Tester. I'd like to edit the query syntax to test more complex queries without the need to connect the cluster through MongoCLI.

Currently, one can't use the autocomplete type to index fields whose value is an array of strings. This is a feature request to allow autocomplete indexing and searching on an array of strings.

Currently, for querying on "date" datatypes, we can only use "range" or "near" operators. The "equals" operator supports querying only "boolean" and "objectId" values, and not date values.

If we want to do equality based matching for date datatypes, then we can leverage "range" using "gt" and "lt" to find it. However this might be sub-optimal in some cases.

Therefore, this is a feature request for having equals operator support date datatype (in addition to boolean and objectId).

Please show how an index is analyzed based on a given index definition.

Currently, the autocomplete data-type doesn't allow for specifying an analyzer, which means it uses the default standard analyzer. Now, the standard analyzer divides text based on word boundaries, making it language-neutral in most cases. However, currently, another language-specific analyzer cannot be specified for autocomplete.

This is a feature request to allow for specifying language-specific analyzers for the autocomplete data-type in the index definitions, in order to fully support autocomplete searching in languages other than English.

I want to use my own encryption key so I know that my search data is encrypted with credentials I manage myself

Currently, if you use the $out aggregation stage to modify a collection with an Atlas Search index, you must delete and re-create the search index. Also, if another collection is renamed with dropTarget:true to an existing collection that already has Atlas Search indexes on it, then it is necessary to recreate the Atlas Search indexes after the collection rename completes (which involves dropping the original collection).

This is a feature request to automatically recreate the pre-existing Atlas Search indexes on a collection after that collection is dropped and recreated (using either $out or renameCollection).

I would like to get only the top scored 1000 or 2000 records while doing the search. Currently this is 2 step process : $search and then use the $limit stage.