Skip to content

Atlas Search

150 results found

  1. Add Atlas Search for Enterprise Advanced

    Due to customer/project constraints, I need to have the ability to use $search to query millions of historical data records with regex and wildcards queries at real-time, on a Enterprise Advanced environment.

    The data cannot be exported to Atlas and it cannot depend on Internet connection, so the functionality must be On-Premises only.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Additional function scores decay functions: exp & linear

    Atlas Search currently only supports gaussian decay function for function scores. In 4 out of 5 of our use cases exp would be a much more natural choice.

    https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#function-decay

    Hopefully that is just a small task!

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. Ruby on Rails support of Atlas Search index management

    Feedback from customer: "Currently we need to manage core DB indexes and atlas search indexes separately. We'd prefer to manage them all in the Rails model code but MongoID only supports core DB index configuration. We're having to use terraform for atlas search index management."

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. 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…

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Allow indexing of synthetic fields

    In order to work around some of the inherent limitations of the Atlas Search capabilities, it would be very useful if we could define and index arbitrary synthetic fields using any normal MongoDB functions & operators. All other Atlas Search capabilities (query, sort, etc.) should support these synthetic fields the same as any other.

    This could possibly be implemented with a new field type and a custom analyzer that supports an aggregate pipeline on the input document and returning the field as its output. This is just an idea, there may be better ways to do it.

    {
      "mappings": {
    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. Sort by a specific array index

    When creating indexes and sorting with "normal" queries, it is possible to index/sort on a specific array index (e.g. foo.0.bar). I do this because the search results grid in our UI only has room to show the first foo.bar result, so it doesn't make sense visually to sort by additional objects which the user can't see.

    Since the new Atlas Search Sort syntax looks the same, I was hoping to do that with it as well, but it doesn't seem possible.

    Example:

    [
      { "xyzzy": "xyzzy",
        "foo": [ { "bar": "A" } ] },
    
      { "xyzzy": "xyzzy",
        "foo": [
    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Allow sort by boolean fields

    When creating indexes and sorting with "normal" queries, it is possible to index/sort on a boolean field. I was hoping to do this with Atlas Search Sort as well, but it only supports date, number and token (string).

    While workarounds are available (using custom scoring), these are not easily combined with multiple sort fields and make programmatically building a query vastly more complex.

    See: https://support.mongodb.com/case/01169728

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. Data type coercion when document field type doesn't match index field type

    When a document field type doesn't match the index field type, it seems to be indexed as "blank" and won't match anything. Many data types are readily convertible between type representations. It would be great if Atlas Search could do that for us and would open up richer functionality by allowing us to use operators/analyzers/etc. on types that don't normally support them.

    My particular use case is to allow searching & sorting on numbers stored as strings. When creating indexes and sorting with "normal" queries, it is possible to sort numbers stored as strings by their numerical ordering rather than…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Token filter that removes duplicated entries

    Create a token filter or a tokenizer or even an option that removes duplicate words in fields  to avoid misleading scoring. 
    For example: if I insert a document with a property "Testing testing document", another with "Testing example" and a third with "Testing foo" and I search for "Testing foo", the first document receives a higher score.
    
    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. Allow comments in JSON code

    It would be great if we could keep comments in JSON generated items such as indexes (both MongoDB and Atlas Search)

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. knnBeta Limitations and Syntax

    I tested the new knnBeta operator today and it worked so far.
    Can we expect the current operator limitations to be gone by release?
    The current limitations make it virtually impossible to use the knn operator as a replacement for previous text operators (like text).
    I would prefer the filter parameter to be omitted and knn not have to be a top-level operator.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. Allow indexing of only part of a collection

    Would be great to be able to create an Atlas Search index that only indexes part of a collection (like partialFilterExpression for a regular index). This would be valuable in situations where a collection is quite large (which would create a lot of unnecessary overhead) but only a small fraction of it needs to be searchable.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. 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/

    9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. wildcard paths in index specifications

    It would make index specification easier in some cases if wildcards were possible in the paths. Yes we have dynamic indexing, but to keep the index size minimal and to be more flexible I want to index only the fields I really need. Consider the following example:

    Example document:

    {
    foo: {
    de: {
    field1: 'bar',
    field2: 'bar'
    },
    en: {
    field1: 'bar',
    field2: 'bar'
    },
    fr: {
    field1: 'bar',
    field2: 'bar'
    },
    }
    }

    Index specification:

    {
    "mappings": {
    "dynamic": false,
    "fields": {
    "foo": {
    "type": "document",
    "dynamic": false,
    "fields": {
    "$**": {
    "type": "document",
    "dynamic": false,
    "fields": {…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. Ability to randomize score

    I would like to be able to add randomness to the search results' score.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. Ability to return all documents in a collection

    I need to return all documents in a collection while boosting certain results which match my search criteria.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. Ability to exclude documents matching a certain criteria from index

    We don't do physical deletion of documents, but a logical one, flagging them by setting a value for a deleted_at field.

    We would like an option to exclude documents where that field exists and is not null from the index, because they will never be returned and are only consuming space of the index.

    Currently we use a mustNot condition to exclude them, but of course they are still being indexed.

    The ideal would be to be able to define the exclusion criteria in the index definition.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. Multiple Capture Groups in RegEx Tokenizer

    Currently the RegEx tokenizer only supports to either create a token from each match or for one capture group per match. This makes it impossible to reuse parts of the text for multiple tokens, for example when you want to tokenize "13.3" into "13" as well as "13.3" (our use case is searching products where we want to find a 13.3" device by searching for 13" as well as 13.3").

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. Allow faceting on boolean fields

    Right now you can only facet on string, number, date fields.
    https://www.mongodb.com/docs/atlas/atlas-search/facet/#facet-definition

    I would like to also be able to facet on boolean fields.

    7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. Duplicate search index

    I want to be able to easily duplicate a search index in the Atlas UI.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?

Atlas Search

Categories

Feedback and Knowledge Base