Defaults to identity — declare a text Analyzer (text_fr, text_en, …) for linguistic matching.

Declared at the View level it applies to every searched field; declared inside a FIELDS entry it overrides that level for the field — so a single View can index a text_fr body and a text_en body, each queried through its own Analyzer. Since the Analyzer is fixed at indexing time, a per-field override is reflected both in the View link and in the query.

A per-field entry also accepts a list of Analyzers (['text_fr', 'autocomplete']): the field is then indexed through every one of them and the query matches under each (one ANALYZER(...) branch per Analyzer, OR-ed). This indexes the same field several ways at once — e.g. a text recipe for whole-word search plus an ngram recipe for autocomplete. The View-level value stays a single Analyzer (the inherited default).

Falls back to the model's AQL::SEARCHABLE list (boost 1) when omitted.

Declared at the View level it applies to every searched field; declared inside a FIELDS entry it overrides that level for the field — an explicit 0 opts a field out (e.g. an identifier) while the rest of the View stays typo-tolerant. A field with no FUZZY key inherits the View-level value.

AQL::SEARCHABLE =>
[
    'name' ,                                                       // public field (plain string)
    [ Search::KEY => 'salary' , Search::REQUIRES => 'hr:salary' ], // gated field
]

Only meaningful inside AQL::SEARCHABLE array entries; Search::FIELDS keeps its map form (field => options) where the field is the key.

Two forms: the analyzer name alone (the threshold falls back to the server default 0.7), or a map carrying the analyzer and an explicit threshold:

Search::NGRAM => 'autocomplete'                                       // default threshold
Search::NGRAM => [ Search::ANALYZER => 'autocomplete', Search::THRESHOLD => 0.6 ]

It is disjoint from ANALYZER: put the text recipes under ANALYZER (whole-word, IN TOKENS, BM25) and the ngram recipe here. The field's BOOST applies to the branch; FUZZY / PHRASE do not. NGRAM_MATCH wants an ngram Analyzer declared with min == max and preserveOriginal: false.

A search term is a comma-separated piece of ?search=; its words are its whitespace-separated pieces. With OR (default) the whole term is matched in one shot (doc.name IN TOKENS("fourcade marc", …)), which the IN semantics resolve as any token — so a search for « fourcade marc » returns every « marc ». With AND the term is split and each word must be found in the same field (doc.name IN TOKENS("fourcade", …) && doc.name IN TOKENS("marc", …)), so only « Fourcade Marc » matches. It only tightens the words inside a field: the OR between comma-separated terms and the OR between fields are untouched (a query never has to match two different fields at once).

Declared at the View level it applies to every field; declared inside a FIELDS entry it overrides that level for the field — so a View can require both words on name while a code field stays loose. A field with no OPERATOR key inherits the View-level value; an absent View-level value is OR. Exact codes (an identifier, a postal code) are unaffected in practice: a single-word query is identical under AND and OR, and a two-word query simply neutralizes their branch (a code never holds both words), which is the wanted behaviour.

The exact-phrase bonus (PHRASE) still applies to the whole term under AND — it ranks « Fourcade Marc » (adjacent, in order) above a scattered match without changing the matched set. Typo tolerance (FUZZY) applies per word.

Declared at the View level it applies to every searched field; declared inside a FIELDS entry it overrides that level for the field — an explicit false opts a field out while the rest of the View keeps the bonus. A field with no PHRASE key inherits the View-level value. PHRASE() requires the field Analyzer to expose the position and frequency features.

• on the AQL::VIEW block → gates the whole search (every field): a denied subject yields a SEARCH that matches nothing, whatever the per-field declarations;
• inside a FIELDS entry → gates that single field.

The same key gates the classic LIKE sweep too: a AQL::SEARCHABLE entry may carry it (via KEY) to make a field searchable only when granted.

The two levels combine with AND (the request must satisfy the View-level requirement and the field's own) — unlike the other per-field facets, where a field value overrides the View level. Within a single list the subjects combine with OR. A level with no REQUIRES adds no constraint; a field is always searchable when neither level gates it.

The decision is delegated to the request authorizer (Arango::AUTHORIZER, see isAuthorized()). With no authorizer injected the gate falls open (authorization layer disabled). If permissions remove every searched field, the SEARCH matches nothing — it never falls back to searching everything.

Two accepted shapes, a string of characters or a list of characters (normalized to the same set) — pick whichever reads better:

Search::SEPARATORS => "-./"                 // string of characters
Search::SEPARATORS => [ "-" , "." , "/" ]   // list of characters

The default (key absent) is the hyphen (-), so a compound term like « Jean-Marc » splits into Jean + Marc and behaves like « Jean Marc » (otherwise the single word re-expands to an OR of its tokens through IN TOKENS, losing the AND). An explicit empty value ("" or []) splits on whitespace only — e.g. to keep hyphenated codes (REF-2024) whole. Characters are regex-escaped, so any punctuation is safe.

Declared on the AQL::VIEW block it drives the View search; the classic LIKE sweep reads the model-level Search::SEPARATORS init key (see SearchTrait::$searchSeparators). Beware widening it to elisions (the apostrophe of « d'Artagnan » would make a one-letter word that empties the AND); the hyphen default stays safe.