Exercise 2: Why category and brand Get a keyword Sub-Field — Possible Solution ==================================================================== WHAT THE CAPSTONE'S OWN MAPPING DOES ------------------------------ Per this chapter's own mapping: "category": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "brand": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, Both fields are mapped as analyzed text (for full-text search purposes) AND given a separate, unanalyzed "keyword" sub-field (category.keyword, brand.keyword) specifically for exact matching and aggregation. CONNECTING THIS TO SEARCH1-3'S OWN DYNAMIC-MAPPING GOTCHA ------------------------------ Per search1-3's own warn-box, if a field's type is inferred automatically rather than declared explicitly, a value's first-ever form can permanently lock in an unsuitable mapping. By explicitly declaring category and brand as text-with-a-keyword-sub-field up front, this capstone avoids leaving that decision to dynamic inference at all — the mapping is deliberate and correct from the very first document indexed, rather than depending on what value happens to arrive first. CONNECTING THIS TO SEARCH1-7'S OWN ANALYZED-FIELD AGGREGATION GOTCHA ------------------------------ Per search1-7's own warn-box, "aggregating directly on an analyzed text field creates buckets per individual token, not per whole value." If category and brand had been mapped as ONLY analyzed text (with no keyword sub-field), the capstone's own by_category and by_brand terms aggregations would bucket by individual TOKEN rather than by whole category/brand name. A CONCRETE EXAMPLE OF WHAT WOULD GO WRONG WITHOUT THE KEYWORD SUB-FIELD ------------------------------ Suppose a product's category value is "Home Office" and its brand is "Logitech." Without a keyword sub-field, running by_category as a terms aggregation directly on the analyzed category field would tokenize "Home Office" into separate lowercase terms "home" and "office," producing two separate, meaningless buckets instead of one coherent "Home Office" category bucket — exactly the same failure mode search1-7's own warn-box described for "Wireless Mouse." The capstone's own price_ranges aggregation and category.keyword/ brand.keyword filter clauses in the combined query specifically rely on the keyword sub-field existing, precisely to avoid this exact outcome — using category.keyword and brand.keyword (the exact, unanalyzed versions) for both the filter clauses and the by_category/ by_brand aggregations, while the plain, analyzed category and brand fields remain available if genuine full-text search against them were ever needed. WHY THIS WORKS AS AN ANSWER ------------------------------ It ties the capstone's own specific mapping decision back to both named prior gotchas individually, and constructs a concrete example (a "Home Office" category tokenizing into two meaningless buckets) showing exactly what would break without the keyword sub-field this capstone deliberately included.