112 results found

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

   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

2. Only run Atlas Search on certain nodes

   Today, Atlas Search runs on all nodes of your cluster. I would like to limit the nodes that queries run on so I can isolate my transactional workload from my search workload.

   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

3. $bucketAuto for number facets

   As a developer, I would like to have functionality for NumberFacets similar to the $bucketAuto operator, so that I can define the number of buckets I want instead of setting the boundaries myself.

   This function is helpful in situations where you don't know the boundaries or can't calculate them easily.

   Example:
   myNumberFacet: {
   type: 'number'
   path: 'path.to.my.field'
   buckets: 1000
   }

   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

4. Hiearchical/Multi-Level filters/facets.

   As a user, I'd like to be able to compute faceted counts on multi-levels of categorization.

   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

5. Automatically recreate Atlas Search indexes on a collection after the collection is dropped and recreated or overwritten

   Currently, if you use the $out aggregation stage to modify a collection with an Atlas Search index, you must delete and re-create the search index. Also, if another collection is renamed with dropTarget:true to an existing collection that already has Atlas Search indexes on it, then it is necessary to recreate the Atlas Search indexes after the collection rename completes (which involves dropping the original collection).

   This is a feature request to automatically recreate the pre-existing Atlas Search indexes on a collection after that collection is dropped and recreated (using either $out or renameCollection).

   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

6. Analzye Endpoint or Analysis Screen

   Please show how an index is analyzed based on a given index definition.

   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

   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

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

   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

   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  ·  AdminElle (Admin, MongoDB) responded

   This work is under review and research. 

8. Support more complex groupings in facets

   The facet collector groups results by values or ranges in the specified faceted fields and it currently returns the count for each of those groups. However, besides counting, it would be good to have facets also support more complex groupings, such as averages.

   This is a feature request to have facets support complex groupings, and expand its capabilities beyond generating counts for various buckets.

   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

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

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

    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

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 Decimal128

    Enable indexing and querying of near and range operators for Decimal128.

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

    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

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

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

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

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

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

    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.

    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