Atlas Search
112 results found
-
Provide features for array comparisons
It would be very helpful if we can lookup documents that have certain array fields that match the provided array in the query. Exact match, Any match etc should be supported. All data types should be supported.
e.g { text: { path: "city", query: ["New York", "Los Angeles", "Kansas"] } } should return all documents that have the city as ["New York", "Los Angeles", "Kansas"].
1 vote -
Filtered Indexes
Provide capability to create filtered indexes. This would allow creating tenant-specific indexes in a multi-tenant database.
While the current implementation does support this feature in a way, it requires manual maintenance of such indexes as there is an implicit assumption that each tenant would have the same fields.
Our core requirement is that each tenant can have their own set of fields. Filtered indexes would help reduce the size, hence requiring fewer system resources and possibly helping the database perform better.
1 vote -
Atlas Search vs find/match
Atlas Search is currently quite rigid and is not as awesome as find/match.
find/match supports a variety of operators that allow looking up documents in numerous ways and is meeting our requirements to be able to query using filters such as:
in, nin, eq, neq, gte, lte, all, any, gt, lt, size
These operators work with find/match for any and all data types including arrays. With arrays, find/match even does an exact match comparison which is one of our requirements.It would be great if we can combine the speed of Atlas Search with find/match features
1 vote -
Support ObjectID as a datatype for search facets
I'm really interested in using search facets to boost search performance, but one of the fields that I want to filter by is an ObjectId.
I believe the only supported facet types are [date, numberFacet, stringFacet].
1 vote -
Faster Search Index Builds
Today, my index build may take a long time (depending on the amount of documents being indexed) and I would like to see these be faster so I am able to develop and iterate faster.
Please comment current build time and preferred build time.
1 vote -
Support for Index Partitions
When I reach Lucene's 2 billion document limit, I would prefer to partition my index instead of being forced to Shard my database.
1 vote -
Extending Range operator support to ObjectId values
If the Range operator supports ObjectId, it'll be really useful for the application that sorts or paginates data using _id, since _id is sorted by default.
1 vote -
Display indexID in the UI
Just like the project ID is displayed on the Project Settings page, please display the index ID somewhere in the UI, so that we know what indexID to put when using the Atlas Search API endpoints (they require indexIDs but the UI displays only index names). That would make management and maintenance much simpler.
Unless I'm mistaken, the only way to know the indexID of an index I see in my UI is to make programmatic calls to some other API endpoints.
1 vote -
Support document-level RBAC for search query results
Users of Elastic may configure role-based security for specific indexed fields or indexed documents. For document-level security, a query filter(s) is associated with a role, and an authenticated search query provides the role. The search engine looks up RBAC rules for the given role and index combination, adds the filter or filters defined for the role and adds the filters as part of a compound search query. This allows an easy form of document-level RBAC so certain roles may search and access only a given set of documents based on one or more filter query fragments.
https://www.elastic.co/guide/en/elasticsearch/reference/current/document-level-security.html
1 vote -
Make the size bigger of Query search results
Hey, recently I saw that in find section, where all data shown, is bit smaller in view point. I mean we can't see properly entire obj. Right now we have only less screen to see it.
Here I have attached two picture of find section. Plz make the screen bigger to see more...
Hope to implement my ideas.....1 vote -
Version + Feature Availability Matrix
As a customer, I would like to know what features work with which versions of MongoDB and Atlas Search.
Does facets work with 4.2, or 4.4, or version 5 for instance.
1 vote -
Did you mean? Spell Checker
I'd like a spelling check feature that will handle cases where the user misspells a word and still match what the user probably intended.
1 vote -
Query_syntax operator should support lucene syntax
At the moment the query_syntax seems to have a custom syntax. It looks similar to lucene syntax but is not the same.
There are a few differences to azure and elastic and I don’t understand whether I am doing something wrong or not.
What all three service have in common is that they are built on top of lucene, therefore I though that the querystring operator uses the lucene query syntax as it seems to be done by elastic and azure: https://lucene.apache.org/core/29_4/queryparsersyntax.html
Documentation about the elastic query string query can be found under: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html
There are a few…
1 vote -
Improve error message when index definition exceeds 3KB
hen you create an index definition on the free plan that exceeds 3KB you get the following message:
{"detail":"A tenant FTS index may not exceed 3 KB in size.","error":400,"errorCode":"TENANTFTSINDEXTOOLARGE","parameters":[],"reason":"Bad Request"}
The message could be clearer. I had no idea what it meant and had to search the docs for that.
The limitations are described here: https://docs.atlas.mongodb.com/reference/atlas-search/limitations/
1 vote -
Add other operators (range/TO, NOT) in queryString
I like lucene query string syntax (https://lucene.apache.org/core/8_10_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package.description). I think it is more human-readable. So, please add the range operator to it and if it's possible, add other ones like NOT, regex, boosting, proximity and fuzzy.
If it's hard, please focus on range and NOT1 vote -
Add support for creating and editing Custom Analyzers via the Visual Editor
The Visual Editor currently does not support creating or editing custom analyzers. This is a feature request for adding support for creating and editing Custom Analyzers via the Visual Editor.
1 vote -
Don't require path on search queries
It would be nice if a path defaults to all paths in the index. For example, imagine I have a customers collections with the fields "firstName" and "lastName" and I want to create a search based on user's full name. Then I create a search index on these two fields. Now imagine I call this index "fullNameSearch". Then whenever the "fullNameSearch" index is used, I want to run it on all paths. Instead of me having to specify the paths, it would be nice if the path defaults to all fields used in the index.
Another example where this would…
1 vote -
Please add lucene.kuromoji
I just happened to know that full-text search feature is available in MongoDB Atlas. Greatly appreciated if lucene.kuromoji is added to a list of language-specific analyzers. Currently, there is only a generic Chinese, Japanese, and Korean analyzer.
1 vote -
1 vote
-
Allow searching of images
We have scanned images with text, and would like to have OCR capabilities so that we can search against those images
1 vote
- Don't see your idea?