-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Component/s: None
-
None
-
Builder Changes Needed
-
Summary
Customers believe all Atlas Search capabilities are supported at the embedded level and are frustrated by lack of feature compatibility. They have to restructure their data to use Atlas Search, post-process $search results, and/or use subsequent aggregation stages to get their desired search results.
Motivation
Who is the affected end user?
Developers
How does this affect the end user?
Performance does not meet customer needs, adoption of Atlas Search becomes blocked and/or opportunities are lost. These customers are frustrated that the recommended MongoDB data model is not well-suited for search capabilities.
How likely is it that this problem or use case will occur?
This affects customers using the embeddedDocuments operator, the 4th-most commonly used operator, embeddedDocuments. This is more prevalent in use cases with highly nested data.
If the problem does occur, what are the consequences and how severe are they?
Customers cannot use Atlas Search.
Is this issue urgent?
NA
Is this ticket required by a downstream team?
NA
Is this ticket only for tests?
NA
Acceptance Criteria
Builders support new syntax for $search and $searchMeta queries
- new top-level parameter `returnScope`
- new top-level operator `hasAncestor`
- new top-level operator `hasRoot`
Builders support new search index syntax:
- Support `storedSource: true | false | include: [] | exclude []` configurations within embeddedDocuments field mapping definitions
- split to
-
CSHARP-5769 Atlas Search: embeddedDocuments improvements
-
- Backlog
-
-
JAVA-5995 Atlas Search: embeddedDocuments improvements
-
- Backlog
-
-
PHPLIB-1738 Atlas Search: embeddedDocuments improvements
-
- Backlog
-