161 results found

1. Mutli-select faceting / facets should not affect their own filter field

   I want to build multi-select facet without having to run separate queries to calculate bucket counts for each active filter. Described in detail here: https://yonik.com/multi-select-faceting/

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Sorting within nested objects. Allow filters on sort operation

   Atlas search sorting currently only supports a direct sort on root level fields or nested fields indexed as type "document": https://www.mongodb.com/docs/atlas/atlas-search/sort/

   Sorting cannot be done in conjunction with a filter, so a sort operation on an array of objects sorts based on the values of every document in the array. Filtering the objects inside the array and then sorting is not supported

   OpenSearch supports sorting with filtering: https://www.elastic.co/guide/en/elasticsearch/reference/current/sort-search-results.html#nested-sorting

   Here is an example of how that is done in elastic search and it would be very useful to have an equivalent feature in Atlas Search:

   POST /_search
   {
      "query": {
         "nested": {
            "path": "parent",
            "query": {
               "bool": {
                   "must": {"range": {"parent.age": {"gte": 21}}},
                   "filter": {
                       "nested": {
                           "path": "parent.child",
                           "query": {"match": {"parent.child.name": "matt"}}
                       }
                   }
               }
            }
         }
      },
      "sort" : [
         {
            "parent.child.age" : {
               "mode" :  "min",
               "order" : "asc",
               "nested": {
                  "path": "parent",
                  "filter": {
                     "range": {"parent.age": {"gte": 21}}
                  },
                  "nested": {
                     "path": "parent.child",
                     "filter": {
                        "match": {"parent.child.name": "matt"}
                     }
                  }
               }
            }
         }
      ]
   }
   

   Atlas search sorting currently only supports a direct sort on root level fields or nested fields indexed as type "document": https://www.mongodb.com/docs/atlas/atlas-search/sort/

   Sorting cannot be done in conjunction with a filter, so a sort operation on an array of objects sorts based on the values of every document in the array. Filtering the objects inside the array and then sorting is not supported

   OpenSearch supports sorting with filtering: https://www.elastic.co/guide/en/elasticsearch/reference/current/sort-search-results.html#nested-sorting

   Here is an example of how that is done in elastic search and it would be very useful to have an equivalent feature in Atlas Search:

   POST /_search
   {
      "query": {
         "nested":

   … more
   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Allow faceting on decimal fields

   I'd like to create a facet on a Price field stored as a decimal in my MongoDB documents. However, this doesn't give me the results I expect. I'm required to set the "boundaries" property on the facet to an array of integer or double values. However, when the facets are returned, they are all thrown into the "default" bucket.

   For example, if I were to declare the facet like this:

       facets: {
         price: {
           type: "number",
           path: "ProductPrice",
           // using plain integer boundaries 0,10,20,30 also fails
           boundaries: [ 0, 5.00, 10.00, 15.00, 20.00, 25.00, 30.00 ],
           default: "other",
         },
       },
   

   I incorrectly get results like this:

   "facet" : {
       "price" : {
           "buckets" : [
               {
                   "_id" : 0.0, 
                   "count" : NumberLong(0)
               }, 
               {
                   "_id" : 5.0, 
                   "count" : NumberLong(0)
               }, 
               {
                   "_id" : 10.0, 
                   "count" : NumberLong(0)
               }, 
               {
                   "_id" : 15.0, 
                   "count" : NumberLong(0)
               }, 
               {
                   "_id" : 20.0, 
                   "count" : NumberLong(0)
               }, 
               {
                   "_id" : 25.0, 
                   "count" : NumberLong(0)
               }, 
               {
                   "_id" : "other", 
                   "count" : NumberLong(1304)
               }
           ]
       }
   }
   

   Instead of having my results distributed across my price ranges.

   I'd like to create a facet on a Price field stored as a decimal in my MongoDB documents. However, this doesn't give me the results I expect. I'm required to set the "boundaries" property on the facet to an array of integer or double values. However, when the facets are returned, they are all thrown into the "default" bucket.

   For example, if I were to declare the facet like this:

       facets: {
         price: {
           type: "number",
           path: "ProductPrice",
           // using plain integer boundaries 0,10,20,30 also fails
           boundaries: [ 0, 5.00, 10.00, 15.00, 20.00, 25.00, 30.00 ],
           default: "other",
         },
       },
   

   … more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Allow $match syntax in $search queries

   Currently, I am re-writing my queries that were previously using $match + $text queries using $search + compound. Firstly, this is a fair bit of work depending on the number of match clauses etc. Secondly, not all the operators that $match supports are supported inside $search/compound clauses causing product differences.

   Anything that would speed up migrating $match queries to use $search while maintaining query results would help take advantage of the $search capabilities without having to rework the entire query logic.

   As a side note, I'm aware that $match can follow a $search stage, but unfortunately this is really not performant as the $match stage is unable to use any of the native indices as confirmed by the documentation. There is another idea around allow $match to go before $search (which is great, I've upvoted). That could also help with this request as long as the performance can be figured out while handing off from the $match stage to the $search stage.

   Currently, I am re-writing my queries that were previously using $match + $text queries using $search + compound. Firstly, this is a fair bit of work depending on the number of match clauses etc. Secondly, not all the operators that $match supports are supported inside $search/compound clauses causing product differences.

   Anything that would speed up migrating $match queries to use $search while maintaining query results would help take advantage of the $search capabilities without having to rework the entire query logic.

   As a side note, I'm aware that $match can follow a $search stage, but unfortunately this is really not… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Errors When Querying Non-existent Indexes

   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

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   under review  ·  Elle responded

   This work is under review and research. 

6. Non-sequential or Deep Pagination

   I want to be able to paginate results in non-sequential order, e.g. Skip from page 1 to 5, or skip from first to last page of results

   8 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Provide the ability to auto-scale dedicated search nodes

   Currently, dedicated search nodes in Atlas Search cannot be auto-scaled. This is a feature request to introduce the ability to auto-scale dedicated search nodes.

   8 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Support min-max computation for number and date fields, within Atlas Search

   Currently, the $min and $max aggregation operators can be used in a number of aggregation pipeline stages, in order to find min/max values for fields. It would be great if either these operators were supported within $search, or if there was a way to compute the min-max values for number and date fields within Atlas Search itself. There are certain use-cases where such a functionality can prove useful.

   For instance, we can leverage the $near operator to get sorted results, and determine the sort order of the results based on the origin. However, many times, the min-max values for the field might not be known beforehand, and thus determining what value of "origin" to use in the query can be challenging. However, if there was a way to compute the min or max of a field within $search itself, then it would really be helpful for those use-cases. If such a functionality were implemented, it could be used in a way that could be something like this:

   near": {
                   "origin": "max" / "min",
                   "path": "rating",
                   "pivot": 1
   }
   

   Currently, the $min and $max aggregation operators can be used in a number of aggregation pipeline stages, in order to find min/max values for fields. It would be great if either these operators were supported within $search, or if there was a way to compute the min-max values for number and date fields within Atlas Search itself. There are certain use-cases where such a functionality can prove useful.

   For instance, we can leverage the $near operator to get sorted results, and determine the sort order of the results based on the origin. However, many times, the min-max values… more

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Save pipelines to run in aggregation mode

   A Button to save pipeline in aggregation tab and run this saved pipelines.

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   under review  ·  Rez responded

   Danilo – Great idea. We are reviewing it at the moment. Just curious whether you use the agg tab to do adhoc analysis or test queries which you eventually put in your app?

10. Support pagination when sorting by searchScore on Search Nodes

    Using searchAfter / searchBefore on Search Nodes when sorting by searchScore can be inconsistent.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Atlas Search Local Deployment Lucene Indexing Latency of 1s

    We are unit testing our Java application using the (awesome!) Atlas Search Local Deployments.

    However, we are seeing a longer delay than we'd like between the time we add data to a collection and the time it is searchable in the Atlas Search Lucene index.

    It is almost always uniformly 1 second.

    Here's a unit test that demonstrates the issue:
    https://github.com/luketn/atlas-search-unit-test-latency-issue/blob/main/src/test/java/com/mycodefu/MainTest.java#L95

    This should take a few milliseconds to run, but it will take almost exactly a minute.

    Each iteration of the loop in the test will take almost exactly 1s.

    The first iteration will usually be shorter, because we start somewhere in the middle of the 1s refresh period:

    Time taken for search query to find document: 556ms

    Example output of iterations:
    > Time taken for search query to find document: 1009ms
    > Time taken for search query to find document: 989ms
    > Time taken for search query to find document: 1018ms

    Output at the end:
    > Time taken for test to run: 60s

    It may be sensible in production use cases for the eventual consistency of Atlas Search to be 1s. However during unit testing this presents a real problem.

    I'm not sure what the best solution would be, but perhaps the indexes could be made available in a more realtime fashion (particularly for unit testing).

    A couple of ideas for a solution:
    - allow a write concern by connection or insert/update which triggers immediate refresh of the Atlas Search indexes so that you could selectively
    - instead of using a periodic refresh on a 1s basis, update the queryable indexes in real time as changes are written (not sure if there are tradeoffs)
    - support a command which can be used to trigger an update on Atlas Search indexes

    We are unit testing our Java application using the (awesome!) Atlas Search Local Deployments.

    However, we are seeing a longer delay than we'd like between the time we add data to a collection and the time it is searchable in the Atlas Search Lucene index.

    It is almost always uniformly 1 second.

    Here's a unit test that demonstrates the issue:
    https://github.com/luketn/atlas-search-unit-test-latency-issue/blob/main/src/test/java/com/mycodefu/MainTest.java#L95

    This should take a few milliseconds to run, but it will take almost exactly a minute.

    Each iteration of the loop in the test will take almost exactly 1s.

    The first iteration will usually be shorter, because we start… more

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Ability to Upsert an Atlas Search Index

    Currently, it is possible to use createSearchIndex and updateSearchIndex to create and update search indexes, respectively. It would be beneficial if the updateSearchIndex allowed 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 leveraging getSearchIndexes().

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Feedback on the Atlas Search Visual Index Builder

    How can we improve?

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    5 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Support full Lucene Query Parser syntax in $search

    I’m looking to expose “power user” queries through our UI, but the queryString operator only works on string data types, and is somewhat too simplistic for this purpose.

    Obviously, accepting raw user inputs and directly building a query from it is a security risk, but using something like queryString (which I do currently) seems like a safer and/or easier option.

    I would like to see a new $search operator (perhaps "lucene" or "query") that accepts the full Lucene Query Parser Syntax.

    https://lucene.apache.org/core/2_9_4/queryparsersyntax.html

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Use case driven search operators and index types

    Examples: phone numbers, addresses, websites, emails

    If this would be helpful for you, please comment the data type you are looking for

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Percolator for Atlas search to support Reverse look ups

    Percolator for Atlas search to support Reverse look ups for real estate property data

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Autocomplete with `fuzzy` scores all results as `1`

    Using autocomplete with the fuzzy operator 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

    https://developer.mongodb.com/community/forums/t/trying-to-understand-atlas-search-autocomplete-result/13819

    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.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Atlas Search for Online Archive

    As a user of Online Archive, I would like full text search capabilities from Atlas Search available to me.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Support additional highlighting options

    Right now Atlas Search highlighting only supports text in the sentence surrounding a match, ignoring any other sentences in a field that have also been indexed.

    I would like to be able to change the default behavior to meet my needs.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    under review  ·  1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Support filtering by empty array

    Atlas Search should support matching a fields set to an empty array. This behavior is not supported by either of the exists, equals, or in operators, and is a very common use case.

    https://search-playground.mongodb.com/tools/code-playground/snapshots/668bd0688e71d69d70fc71dd

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating