153 results found

1. 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
   under review  ·  Elle responded

   This work is under review and research. 

2. 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

   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

3. 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

   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

4. 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
   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?

5. 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

6. 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

   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

7. 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

8. 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

9. 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

10. 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.

    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

11. Index Templates

    I'd like the ability to apply index templates or field level mappings for my indexes

    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

12. Introduce the ability to "forecast the Atlas Search index-size" in advance, before starting the index build

    Currently, prior to building an Atlas Search index, there is no way for users to know how large that index can get. Knowing the projected-index-size in advance can especially be helpful for users who might need to build index on a large collection, and where building such an index can push the disk-utilization to the max.

    Therefore, this is a feature request to implement a way to "forecast the Atlas Search index-size" in advance, before starting the index build.

    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

13. Percolator for Atlas search to support Reverse look ups

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

    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

14. Allow to create Atlas Search index on a not existing collection

    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.

    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

15. Percolator/reverse search

    Ability to store queries that allow you to supply a document and return the queries that match it.

    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

16. Allow the option to mention the number of search results needed

    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.

    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

    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

17. New Analyzers

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

    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

    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
    planned  ·  Marcus Eagan responded

    We have planned to add more analyzers.

18. 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

    4 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

19. 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 indexed, run them through the pipeline and then send them to the Atlas Search engine for indexing.

    Here's what that might look like:

    {
      "mappings": {
        "dynamic": false,
        "aggregate": [
          { <stage> },
          ...,
          {
            "$addFields": {
              "my-synthetic-field": <expression>
            }
          }
        ],
        "fields": {
          "my-synthetic-field": {
            "type": "string"
          }
        }
      }
    }
    

    Here are some of the other suggestions I (or others) have made that could be solved with this approach:

    https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049898-allow-indexing-of-synthetic-fields
    https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049757-data-type-coercion-when-document-field-type-doesn
    https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049775-allow-sort-by-boolean-fields
    https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049775-allow-sort-by-boolean-fields
    https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/40734700-support-decimal128

    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… more

    4 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

    started  ·  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

20. 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.

    4 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