158 results found

1. MongoT (Atlas Search) logs available

   Provide mongot logs (Atlas Search) available to the customers to be downloaded and analyzed like right now it is possible to download and analyze mongod logs (classic db).

   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

   0 comments  ·  Monitoring and Metrics  ·  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

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

   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

   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

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

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

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

   This work is under review and research. 

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

   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

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

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

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

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

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

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

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

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

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

    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

    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

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

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

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

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

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