Exercise 3: The Analyzed-Field Aggregation Gotcha, and Its Two Prior Echoes — Possible Solution ==================================================================== THE GOTCHA, WITH A CONCRETE EXAMPLE ------------------------------ Per this chapter's own warn-box, "aggregating directly on an analyzed text field creates buckets per individual token, not per whole value — a category field containing 'Wireless Mouse' would bucket into separate 'wireless' and 'mouse' buckets, rather than one distinct 'Wireless Mouse' category." Concretely: suppose a category field is mapped as an ordinary analyzed text field, and products are tagged with category values like "Wireless Mouse" and "Wired Keyboard." A terms aggregation on this analyzed field wouldn't produce two buckets ("Wireless Mouse": N products, "Wired Keyboard": M products") the way a faceted-search sidebar would want — because search1-4's own analyzer material tokenizes "Wireless Mouse" into separate lowercase terms "wireless" and "mouse" before it's ever added to the index, and the aggregation operates on THOSE stored terms, not the original whole value. The result would be scattered, meaningless buckets like "wireless," "mouse," "wired," and "keyboard" individually, rather than the two coherent category buckets actually wanted. THE FIX ------------------------------ Per this chapter, "the fix is a 'keyword' sub-field — an exact, unanalyzed mapping alongside the analyzed text field — used specifically for aggregation and exact-matching purposes." Rather than aggregating on the analyzed category field directly, the mapping includes a second, unanalyzed "keyword" version of the same field (commonly addressed as category.keyword), which stores the value exactly as given ("Wireless Mouse," not split into tokens), and it's THAT keyword sub-field the terms aggregation should actually run against. WHY THIS IS THE SAME UNDERLYING TENSION SEEN TWICE BEFORE ------------------------------ Per this chapter, "this is genuinely the same underlying analyzed-vs- exact tension already seen twice: search1-3's own mapping material, and search1-5's own match-vs-term distinction — now showing up a third time, in a third context." search1-3 introduced the basic idea that a field's mapping determines how it's processed and stored. search1-5's own match-vs-term distinction was fundamentally about querying — match analyzes the search input to compare against analyzed, tokenized terms, while term compares the raw, unanalyzed input against the raw indexed value. This chapter's own aggregation gotcha is the identical underlying tension, but showing up during AGGREGATION rather than querying: aggregating against the analyzed version of a field operates on tokenized pieces (like a match query would), while aggregating against the keyword sub-field operates on the exact, whole value (like a term query would). All three chapters are really teaching one recurring lesson from three different angles: analyzed fields are for full-text matching (search1-5) and are unsuitable for exact grouping/aggregation (this chapter) precisely because of how they're processed at mapping/index time (search1-3). WHY THIS WORKS AS AN ANSWER ------------------------------ It constructs a concrete example of the gotcha using the chapter's own category field scenario, states the fix precisely, and explicitly traces the shared underlying mechanism (analyzed/tokenized vs. exact/ whole-value) across all three chapters rather than treating them as three unrelated facts.