Types in Makaira

Types in Makaira are useful for those who want to use their own fields for searching and filtering. To enable this functionality, data must be delivered with the correct type, which can be ensured by using type suffixes that indicate conversion, also known as casting or mapping.

For example, to set filters using a slider, you should choose the numeric type float or int.

String handling is more complex, as Makaira offers multiple string types, such as short fields, long fields, or fields with proper names. Selecting the correct type is crucial for achieving the desired result.

The table below contains all types with a brief explanation of their use cases.

Custom String Field Suffixes in Makaira

This guide defines the meaning and behavior of suffixes used for string fields in Makaira mappings. Each suffix specifies how a field should be analyzed at index and search time, optimized for different content types such as product titles, descriptions, names, or IDs.

1. _str_short – Short, Structured Text with High Precision

   • Purpose: For short, structured fields like product names or compact attributes.
   • Behavior:
     Index time: Performs compound decomposition, lowercasing, normalization (e.g., umlauts), and stemming.
     Search time: Applies lighter analysis — no decomposition, making searches more exact and controlled.
   • Strength: Optimized for precision — ideal when accurate matching is more important than broad recall.
   • Use Case: Product titles, short attribute values.
   • Example:
     JSON

     {
       "productName_str_short": "Kaffeemaschine mit Milchaufschäumer"
     }
     

2. _str_long – Descriptive Text for Full-Text Search

   • Purpose: For longer free-text fields like product descriptions or marketing text.
   • Behavior: Handles stopwords (e.g., "und", "mit"), lowercasing, normalization, stemming.
   • Strength: Good for rich text search with long inputs and detailed queries.
   • Use Case: Product details, specifications, descriptions.
   • Example:
     JSON

     {
       "description_str_long": "Diese Kaffeemaschine hat WLAN und eine 4K-Anzeige."
     }
     

3. _str_short_key – Proper Names, Unaltered Structure

   • Purpose: For structured names or keys such as brands, manufacturers, or model series.
   • Behavior: Normalized (e.g., lowercased, folded), but no stemming or decomposition. Original structure is preserved.
   • Strength: Maintains integrity of case-sensitive or compound names. Ideal for fields where structure must be retained.
   • Use Case: Brand names, model families, collections.
   • Example:
     JSON

     {
       "manufacturer_str_short_key": "Bosch Professional"
     }
     

4. _str_keyword – Exact Matching Fields

   • Purpose: For fields requiring exact matching, such as SKUs, part numbers, or internal codes.
   • Behavior: No tokenization. Entire value is kept as a single token, lowercased and trimmed.
   • Strength: Ensures exact-match behavior, unaffected by token splitting or stemming.
   • Use Case: Product identifiers, SKUs, internal references.
   • Example:
     JSON

     {
       "sku_str_keyword": "ABC-12345-X"
     }
     

5. _split_number_string – Alphanumeric Split for Model

   • Purpose: Designed for fields that mix letters and numbers (e.g., serials, model codes).
   • Behavior: Splits on letter/number boundaries (e.g., "X1A45Z" → "X", "1", "A", "45", "Z"), applies normalization and stemming.
   • Strength: Improves matchability of complex alphanumerics by enabling partial component search.
   • Use Case: Serial numbers, model numbers, version strings.
   • Example:
     JSON

     {
       "model_split_number_string": "X1A45Z"
     }
     

6. _str_decomposed – High Recall for Search Fields

   • Purpose: For search-relevant fields where broad matching is important.
   • Behavior: Performs full compound decomposition and stemming at both index and search time, ensuring flexible matching.
   • Strength: Optimized for recall — increases the likelihood that various user inputs will hit relevant content.
   • Use Case: Search-focused content fields (e.g., search index, query expansions).
   • Example:
     JSON

     {
       "searchable_str_decomposed": "Milchaufschäumer für Espressomaschinen"
     }
     

{
  // type: *_date
  "marketRelease_date": "2015-01-01T12:10:30Z",
  // type: *_float
  "specialRate_float": 1.258,
  // type: *_int
  "usageScore_int": 150,
  // type: *_bool
  "hasConfiguration_bool": true,
  // type: *_str_short
  "shortDesc_str_short": "A shorter text for the record",
  // type: *_str_long
  "longDesc_str_long": "A very long text can be written",
  // type: *_str_short_key
  "bundleManufacturer_str_short_key": "Bertrand",
  // type: *_str_keyword
  "bundle_str_keyword": "Probierpaket für Einsteiger",
  // type: *_data_only
  "bundle_data_only": {
    "bundleId": 49625,
    "options": {
      "101": "Glas",
      "102": "PVC",
      "103": "Wood"
    }
  }
}

🚧

Please be aware that some functionalities will not work when you do not use attributes, attributeStr, attributeInt, attributeFloat (see benefits of attributes ...).