We need text search to "somehow" work locally and ci.

We've a multiregional team and development has to continue if there are internet problems in one of our offices.

Our workflow consists of :

• unitTest using in-memory-mongodb

• local testing, using the developers local mongo instance

• test env testing with a QA team (using atlas, but <30m)

• production launch

With the current feature set, the first time we can test a feature is on production. Even if low-tier availability was there the other two issues are blockers as we won't just ditch TDD for textSearch.

Currently, (unlike the text operator) the autocomplete operator does not accept a path which is an array of field names. Also, a wildcard path ("path": {"wildcard": "*"}) cannot be specified for an autocomplete query. Therefore, the only way to perform an autocomplete search on multiple fields is by using the compound operator.

This is a feature request to allow autocomplete search on multiple fields by using a wildcard path or by accepting an array of multiple fields in the path.

Currently $search is required to be the first stage in the aggregation pipeline. It would be more intuitive if we could use after other operators, such as $match.

Right now you can only search over one collection. I'd like to be able to search over several collections at the same time.

I would like be able to paginate through search results faster.

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

If we want to do equality based matching for number datatypes, then we can leverage "range" using "gt" and "lt" to find it. However this might be sub-optimal in some cases (such as when performing equality match on decimals).

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

Current faceting solution is not fast enough for search use cases for larger datasets.

It appears that Atlas Search does not yet support nested documents in arrays like MongoDB

https://docs.mongodb.com/v4.2/reference/operator/query/elemMatch/

Currently, when an Atlas backup snapshot from one environment is restored to another environment, it does not transfer or replicate the Atlas Search indexes from the source cluster to the destination cluster. As a result, after the snapshot is restored, the Atlas Search indexes have to be manually created on the collections in the destination cluster.

This is a request for a functionality that will allow a snapshot-restore from one cluster to another to also replicate the Atlas Search indexes from the source cluster to the destination cluster.

Right now it seems like I can query indexes from the mongo shell but not create them, unless I am missing something in the docs?

We have a large collection but would only like to index the most recent entries, which would reduce the amount of space and resources it would take to index and query.

Currently I need to manage my indexes via the Atlas Search API but I would like to manage them using drivers in the same way that I manage all of my other MongoDB indexes.

I am looking to achieve a faster sort when using Atlas Search.

Please comment if you tried Stored Source Fields and it did not meet the performance you were looking for.

Stored Source Fields Docs:
Index - https://www.mongodb.com/docs/atlas/atlas-search/stored-source-definition/
Query - https://www.mongodb.com/docs/atlas/atlas-search/return-stored-source/

The null datatype is not amongst the datatypes that Atlas Search supports at this time. As a result, if the use-case is to perform a text search on some fields and perform an equality/inequality check on other field(s) to see if it is/isn't null, then we need to have a $match stage following the $search stage, which is detrimental to the query performance as documented here. This is an enhancement request to allow indexing and querying for null datatype in Atlas Search, to avoid the above scenario.

Currently, sharded $search queries are scatter-gather queries and they cannot be targeted to specific shards. This is an enhancement request to target $search queries to specific shards, and thereby make them more efficient/performant.

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.

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.

At the moment, an autocomplete index does not tokenize the "@" in email addresses. So when using an autocomplete search on an email address field, the search breaks as soon as the "@" is entered.

I started a thread in the community about this very issue.

https://developer.mongodb.com/community/forums/t/mongo-search-autocomplete-type/10561/5

I would like a metric that shows me what the latency is between the state of the MongoDB collection and the Search index in Atlas.

The difference between the optime of the collection and the optime of the Search index would be the latency. Please consider exposing this metric.