Atlas Search
153 results found
-
Provide a button to cancel in-progress index builds
Currently, the only option for cancelling an in-progress index build is to delete the index using the "Delete Index" menu-item in the Search Tab, or by using the Delete an Atlas Search Index API. This however is not easily evident, if users want to cancel an index build for any reason.
Therefore, this is a feature request to provide a button to "cancel" in-progress index builds from the Atlas UI.
4 votes -
Ability to set a "minimum should match" in a query
I can specify a percent of terms I want to match, for instance 100% means require all terms, 66% means, only return documents that matched at least 60% of the terms. (the default is 1 term)
Ex for 100%
search "foo bar"
"foo bar" "bar foo" "bar hello foo" would all return
"foo hello" would not
4 votes -
Total Document count on Filter
It's a very small feature but very useful with respect to use case, whenever someone filters on Atlas nowhere it shows the total number of result we got, till we didn't reach the last page so it's very useful if we can see the total number of records at least after filtering or it will be great if it is visible on each page.
4 votes -
Add Atlas Search metrics into integration with Datadog
Problem Statement,
Atlas Search metrics (https://docs.atlas.mongodb.com/view-atlas-search-metrics#atlas-search) are not sent to Datadog (Datadog's MongoDB Atlas integration (https://docs.datadoghq.com/integrations/mongodb_atlas/)).Proposal,
Add Atlas Search metrics to Datadog integration (start sending Atlas Search metrics from Atlas to Datadog).4 votes -
Allow queries with $search to be covered by the Lucene indexes without loading from disk in Mongo
If the fields to be filtered on or projected on are all in the Lucene index, it would give the best latency to be able to return the data from the Lucene index only, and not have to separately look that data up from the Mongod
4 votes -
Official React Component for Atlas Search
One of the reasons Algolia got so popular might be the fact that they provided instantsearch.js. The library was really easy to get started and intuitive to understand.
I read the Atlas Search's great tutorial(1) and watched the video(2) and cloned the repo FTS_MovieSearch on GitHub. They are really insightful and helpful. Yet, if there is official React component which provides some of (not all) functionalities that instasearch.js offers, that would help Atlas Search to grow.
(I put "React" in title, but maybe vanilla JS/TS component would be better to consider)
I used to try setting up Atlas + Elastic…
4 votes -
Allow search users to bring their own encryption key
I want to use my own encryption key so I know that my search data is encrypted with credentials I manage myself
4 votes -
Ability to Upsert an Atlas Search Index
Currently, it is possible to use
createSearchIndexandupdateSearchIndexto create and update search indexes, respectively. It would be beneficial if theupdateSearchIndexallowed for upsert functionality, so that if the index does not exist, it can be created. This functionality would be useful in certain scenarios where the indexes are created (if they don't exist) or updated (if they do exist) programmatically, which have to rely on implementing a custom if-else logic by leveraginggetSearchIndexes().3 votes -
Support highlights in embeddedDocuments autocomplete
According to docs, currently it is not possible to get highlights inside embeddedDocuments, in autocomplete requests.
This makes array of objects (embeddedDocuments) autocomplete unusable in our use case.
3 votes -
Add Atlas Search for Enterprise Advanced
Due to customer/project constraints, I need to have the ability to use $search to query millions of historical data records with regex and wildcards queries at real-time, on a Enterprise Advanced environment.
The data cannot be exported to Atlas and it cannot depend on Internet connection, so the functionality must be On-Premises only.
3 votes -
Allow aggregate pipeline on input documents before Atlas Search indexing
If Altas Search allowed us to apply an aggregate pipeline to input documents before they are sent to Atlas Search for indexing, it would open up a TON of new possibilities not currently supported. We could do data transformations, type conversions, synthetic fields, etc.. I've opened up a number of other suggestions for these things, but an input aggregate pipeline could solve all of them in one "easy" solution. Since aggregate pipelines already exist and are deeply embedded in MongoDB, I'm hoping it would be trivial to implement as well. Simply pick up one or more new documents to be…
3 votes -
Allow sort by boolean fields
When creating indexes and sorting with "normal" queries, it is possible to index/sort on a boolean field. I was hoping to do this with Atlas Search Sort as well, but it only supports date, number and token (string).
While workarounds are available (using custom scoring), these are not easily combined with multiple sort fields and make programmatically building a query vastly more complex.
3 votes -
add a setting to ignore the corpus term frequency for score calculation
indexOption:docs omits per document frequencies, but it still uses the corpus frequency.
it would be good to have a setting to ignore the corpus frequency as well
3 votes -
Atlas full text search should support searching all field types
Atlas full text search should support searching all fields types including text, dates, numbers and booleans.
Atlas full text search at present supports searching in text values only. e.g. Searching for "2022" will not pick up documents that contain 2022 in the number fields.
The functionality in it's current form does not have any way of searching for a given string value (which can be numeric, boolean or part of a date).
3 votes -
enable $and operator for multiple words in a search term (not only $or)
It seems a commonly needed ability to decrease the amount of results from a multi-word search query instead of expanding it, since the default operator for every word is $or. If there could be a built-in $and option it will be great. Thank you.
3 votes -
RBAC for Atlas Search
Atlas Search Indexes can only be managed via MongoDB credentials (Terraform or API calls), with required role "Project Data Access Admin" (see https://docs.atlas.mongodb.com/reference/api/fts-indexes-create-one/#required-roles ). It would be great if we could create/delete search indexes using database credentials, similarly to regular indexes.
Because of that constraint, we need to provision dedicated apikey for our application ; in order to create the relevant search indexes. However, providing "Project Data Access Admin" is too much of a security risk - considering the power of such role.
Would it be possible to have dedicated "Atlas Search Admin" role which would allow creation / updating…
3 votes -
wildcard path support for range operator
Currently wildcard path can be constructed to 4 operator(text, phrase, wildcard and regex). Some use cases will be there to use the wildcard path for numeric which can be used by range operator
{ a : { "6578ghg" : { value : "not 55" } } }
{ a : { "9578uhg" : { value : 55 } } }Above 2 document if we have dynamic mapping of search index and below query cannot be used as range does not support wildcard in path:
db.dates.aggregate([ { $search :{ index:"synonyms", compound:{filter:[{text:{query:"55",path:{wildcard:"metadata.*.value"}}},{range:{gte:55,lte:55,path:{wildcard:"metadata.*.value"}}}]}}}])Is there any plans/restriction for adding wildcard path support…
3 votes -
Autocomplete with `fuzzy` scores all results as `1`
Using autocomplete with the
fuzzyoperator returns results, but they are scored all with the same value (1). This has been reported a couple times in the developer forum as well:https://developer.mongodb.com/community/forums/t/fuzzy-autocomplete-score/13341/4
This can make it difficult to process and rank results on the client side, especially for high volumes of returned documents. It would be helpful if autocomplete + fuzzy would support relative scoring.
3 votes -
The equals operator should support date datatype
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).
3 votes -
Support unstructured text entity recognition
We have unstructured text and would like Atlas Search to detect important entities so that we can use them for relevance and ranking
3 votes
- Don't see your idea?