Pre local cleanup

erikhatcher · erikhatcher · commit 2db842cbe188 · 2025-09-17T05:48:47.000-04:00
diff --git a/docs/20_Intro_to_Atlas_Search/2_aggregation_stages.mdx b/docs/20_Intro_to_Atlas_Search/2_aggregation_stages.mdx
@@ -15,20 +15,18 @@ Results are returned in descending **score** order or in an optional `sort` orde
 
 ## $searchMeta
 
-TODO: It was mentioned that searchMeta perhaps doesn't warrant (much) coverage in this
-workshop. Perhaps only mention but do no cover?
-
 Returns a single document of search result metadata including count of matching documents
 and any facets requested. No actual collection documents are returned.
 
 The `$searchMeta` stage performs the same search that `$search` does,
 but only returns the results metadata, not actual matching documents.
 Results metadata includes the count of matching results and facets.
 This same metadata is available when using `$search` too, 
-accessible in the $$SEARCH_META context variable.
+accessible in the `$$SEARCH_META` context variable.
 
 ## Post $search-stages
 
-  * Such as $sort, $group, etc any stage that consumes **all** documents from previous stage.
-  * $limit, $addFields, $project and the like are fine as they only operate on one doc at a time
+  * Warning: stages such as `$sort`, `$group`, and others will consumes **all** documents from previous stage
+    (and could be a performance issue)
+  * `$limit`, `$addFields`, `$project` and the like are fine as they only operate on one doc at a time
     or cut-off
diff --git a/docs/30_Index_configuration/5_string.mdx b/docs/30_Index_configuration/5_string.mdx
@@ -26,7 +26,7 @@ This field type is paired with an operator by the same name to provide partial,
 Careful though - while this field type sounds alluring and does match sub-strings, it does not by
 itself provide good relevancy or highlighting and can explode the index size.
 
-The `autocomplete` field type and operator use complex analysis and querying technique build upon the Analysis techniques in the next section and will be covered a bit more there.
+The `autocomplete` field type and operator use complex analysis and querying techniques, building upon the analysis techniques in the next section and will be covered a bit more there.
 
 ## `string`
 
diff --git a/docs/30_Index_configuration/9_advanced.mdx b/docs/30_Index_configuration/9_advanced.mdx
@@ -43,6 +43,4 @@ To map that GeoJSON `location` field to a `geo` type in Atlas Search:
 
 Operates on numbers and dates, but trickier than `equals`, `in`, and `range`
  * <Link to="https://www.mongodb.com/docs/atlas/atlas-search/near/">near operator</Link>
- * Playground TODO: number `near`
- * Playground TODO: date `near`
 
diff --git a/docs/40_Analysis/9_advanced.mdx b/docs/40_Analysis/9_advanced.mdx
@@ -11,7 +11,7 @@ See also: <Link to="https://www.mongodb.com/solutions/solutions-library/as-you-t
 
 ## partial matching
   * <Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/68a752755ec5d0d84cbffc3b">🔗 `regex`</Playground>
-  * `wildcard`: TODO
+  * `wildcard`: similar to `regex`
 
 ## `moreLikeThis`
 
@@ -28,12 +28,5 @@ https://search-playground.mongodb.com/tools/code-playground/snapshots/6683c8bc4a
 
 # `searchAnalyzer` vs. `analyzer` and which one is chosen when
 
-# Using scoreDetails to glimpse analysis in action:
-
-....
-
-# Configuration options on strings
-
-  * `storedSource`
-  * `synonyms`
-
+* generally use the same analyzer for both (by specifying *only* `analyzer`)
+* when index analysis emits multiple tokens per word, a different `searchAnalyzer` could be warranted
diff --git a/docs/50_Querying/1_index.mdx b/docs/50_Querying/1_index.mdx
@@ -32,4 +32,6 @@ A phrase match can be a bit loose, such that it can match even if there are addi
 
 ## synonyms
 
+When configured and requested, synoyms are applied at query-time with `text` and `phrase`.
 
+Documentation: <Link to="https://www.mongodb.com/docs/atlas/atlas-search/synonyms/">Define Synonym Mappings in Your Atlas Search Index</Link>
diff --git a/docs/50_Querying/7_compound.mdx b/docs/50_Querying/7_compound.mdx
@@ -16,4 +16,4 @@ A `compound` operator holds these four sets of clauses, each an array of any oth
 
 If there's only a single `should` clause in all of a `compound`, it effectively becomes an implicit `must`.
 
-TODO: add some blurb about `minimumShouldMatch`
+When there are multiple `should` clauses, at least `minimumShouldMatch` of them must match; only one clause must match with a default `minimumShouldMatch` of 0.
diff --git a/docs/50_Querying/8_Exercises/1_.mdx b/docs/50_Querying/8_Exercises/1_.mdx
@@ -3,7 +3,7 @@
 Look back at the first chapter of this section to understand how `text` can be configured to match
 in looser/fuzzier ways, then tackle these exercises.
 
-# matchCriteria
+## matchCriteria
 
 <Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/679c8e77e97570c2714a07f2">🔗 Playground link: all terms do no match</Playground> 
 
@@ -20,7 +20,7 @@ Loosen up this query so the document matches.
 </details>
 
 
-# fuzzy
+## fuzzy
 
 <Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/679c915dd0df60f0254e5d51">🔗 Playground link: Adjust the `text` operator settings so that this document matches</Playground>
 <details>
diff --git a/docs/50_Querying/8_Exercises/4_.mdx b/docs/50_Querying/8_Exercises/4_.mdx
@@ -1,4 +1,63 @@
 # Exercises: `compound`
 
-## 
+## minimumShouldMatch
 
+<Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/68ca7d929998a1882cce707c">🔗 Playground link: adjust minimumShouldMatch</Playground> 
+<details>
+  <summary>Solution</summary>
+  <div>
+    ```js
+    "minimumShouldMatch": 2
+    ```
+
+    Increase minimumShouldMatch to increase precision of results.
+  </div>
+</details>
+
+## filter
+
+You've got Products, each with a `name` and a `category`. A user is looking for accessories for a "camera", not actual cameras. Let's guide the user:
+
+<Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/68ca7ff59998a1882cce7080">🔗 Playground link: filter by category</Playground> 
+<details>
+  <summary>Solution</summary>
+
+  You might first try adding an `equals` on `category` within `compound.filter`:
+  <div>
+    ```js
+        filter: [
+          {
+            equals: {
+              path: "category",
+              value: "Accessories"
+            }
+          }
+        ]
+    ```
+  </div>
+
+  Which leads us to this, which isn't yet working:
+  <Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/68ca7f902af20a4fd56dbf22">🔗 Playground link: filter by category not working yet</Playground> 
+
+  Note the surprising effect of querying a path that was not indexed specifically for that operator!
+  
+  Using `equals` on a string field effectively requires that it be mapped as type `token`:
+  <div>
+    ```js
+      {
+        "mappings": {
+          "dynamic": true,
+          "fields": {
+            "category": [
+              {
+                "type": "token"
+              }
+            ]
+          }
+        }
+      }
+    ```
+  </div>
+
+  With this final solution: <Playground url="https://search-playground.corp.mongodb.com/tools/code-sandbox/snapshots/68ca7f009998a1882cce707e">🔗 Playground link: filter by category solution</Playground> 
+</details>
diff --git a/docs/50_Querying/9_advanced.mdx b/docs/50_Querying/9_advanced.mdx
@@ -2,7 +2,7 @@
 
 ## `autocomplete`
 
-This seems an aluring one to run with, but understand that it uses some advanced Lucene analysis
+This seems like an appealing operator, but understand that it uses some advanced Lucene analysis
 techniques with shingling and ngramming that apply differently between index and search time. It's recommended to explore and understand the capabilities and limitations with other textual analysis configurations and query constructions and then come back to this one with good understanding of the tradeoffs of hyper-indexing to facilitate direct short query to index lookup to simpler indexing with more complex query-time searches.
 
 ## `text.fuzzy` options
@@ -11,8 +11,4 @@ A myriad of parameters. Just don't forget about mixing and matching different le
 
 ## `queryString` 
 
-yeah, why not!  TODO
-
-## `moreLikeThis`
-
-TODO
+The `queryString` operator is niche, using specialized, and brittle, syntax.  We strongly recommend using the other operators, in conjuction with `compound`, to build a robust query.
diff --git a/docs/90_Summary.mdx b/docs/90_Summary.mdx
@@ -4,7 +4,8 @@ Congratulations!
 
 ## Search Demo Builder
 
-Do a demonstration of this tool, discussing it's sweet spot
+Check out the 
+[Search Demo Builder](https://search-playground.mongodb.com/tools/search-demo-builder/snapshots/new) - a handy way to jump start a project.
 
 ## Search topics not covered here
 
@@ -13,4 +14,5 @@ Do a demonstration of this tool, discussing it's sweet spot
 * Highlighting
 * Pagination
 * partitioned indexes / index enrichment (new preview feature)
+* more flexible field mapping (coming soon)
 

Original file line number	Diff line number	Diff line change
`@@ -32,4 +32,6 @@ A phrase match can be a bit loose, such that it can match even if there are addi`
`32`	`32`
`33`	`33`	`## synonyms`
`34`	`34`
	`35`	+When configured and requested, synoyms are applied at query-time with `text` and `phrase`.
`35`	`36`
	`37`	`+Documentation: <Link to="https://www.mongodb.com/docs/atlas/atlas-search/synonyms/">Define Synonym Mappings in Your Atlas Search Index</Link>`
Original file line number	Diff line number	Diff line change
@@ -16,4 +16,4 @@ A `compound` operator holds these four sets of clauses, each an array of any oth
`16`	`16`
`17`	`17`	If there's only a single `should` clause in all of a `compound`, it effectively becomes an implicit `must`.
`18`	`18`
`19`		-TODO: add some blurb about `minimumShouldMatch`
	`19`	+When there are multiple `should` clauses, at least `minimumShouldMatch` of them must match; only one clause must match with a default `minimumShouldMatch` of 0.