@tellaro/tql 1.4.3 → 2.0.0

package/dist/src/validator.js

@@ -1,22 +1,110 @@
-import { parseTql as g } from "./parser.js";
-const c = {
-  // Equality (all types)
-  eq: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  ne: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  "=": ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  "==": ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  "!=": ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
+import { parseTql as w } from "./parser.js";
+const c = 1e3, i = [
+  "text",
+  "keyword",
+  "long",
+  "integer",
+  "short",
+  "byte",
+  "double",
+  "float",
+  "half_float",
+  "scaled_float",
+  "unsigned_long",
+  "date",
+  "boolean",
+  "ip",
+  "nested",
+  "object",
+  "geo_point"
+], u = [
+  "long",
+  "integer",
+  "short",
+  "byte",
+  "double",
+  "float",
+  "half_float",
+  "scaled_float",
+  "unsigned_long"
+], a = [...u, "date", "keyword"], g = [...u, "date"], f = {
+  // Equality (all types) — and now that is what it says.
+  //
+  // The transcribed twelve-element list this replaces claimed "all types" while omitting
+  // five: `short`, `byte`, `half_float`, `scaled_float` and `unsigned_long` are all in the
+  // `TqlFieldType` union and were all absent, so `port eq 443` on a `short` field warned
+  // that equality "may not work well" with it.
+  eq: i,
+  ne: i,
+  "=": i,
+  "!=": i,
   eq_ci: ["text", "keyword"],
-  // Comparison (numeric and dates)
-  gt: ["long", "integer", "double", "float", "date"],
-  gte: ["long", "integer", "double", "float", "date"],
-  lt: ["long", "integer", "double", "float", "date"],
-  lte: ["long", "integer", "double", "float", "date"],
-  ">": ["long", "integer", "double", "float", "date"],
-  ">=": ["long", "integer", "double", "float", "date"],
-  "<": ["long", "integer", "double", "float", "date"],
-  "<=": ["long", "integer", "double", "float", "date"],
+  // Ordered comparison — numeric, date, AND keyword.
+  //
+  // `keyword` is not a courtesy. `compare_ordered` in `tql/src/comparator.rs` tries numbers
+  // first and falls back to a LEXICOGRAPHIC string comparison when both sides are strings,
+  // Python does the same, and Python's own validator lists all four in `keyword_ops`
+  // (`_validate_simple_type_compatibility`). Warning here was a false positive against every
+  // layer at once — `host.name gte "m"` is a query the editor flagged, the validator
+  // accepts, the evaluator answers and the cluster serves.
+  //
+  // `text` stays out, and that is the same source's judgement rather than an omission:
+  // `text_ops` excludes the four, because a range over an ANALYZED field compares tokens
+  // rather than the value the user typed. `between` also stays out — see the note on it.
+  //
+  // Every numeric width is listed via ALL_NUMERIC_FIELD_TYPES so the five narrow ones cannot
+  // fall out again the way they did from `eq`.
+  gt: a,
+  gte: a,
+  lt: a,
+  lte: a,
+  ">": a,
+  ">=": a,
+  "<": a,
+  "<=": a,
   // String operations
+  //
+  // ## The `_cs` operators list `text`, and that is deliberate — see below
+  //
+  // Both engines now REFUSE every `_cs` operator when the field cannot answer it: an
+  // ANALYZED field with no case-preserving subfield. The analyzer lowercased every token it
+  // indexed, so the case the query asks about is not in the index at all; before the refusal
+  // both engines fell back to the analyzed field and returned zero hits with no error.
+  //
+  // ALL EIGHT are covered, and the set arrived in two commits rather than one, which is why
+  // it is stated as a rule and not as a list of six:
+  //
+  //   * `a3971bd` — `contains_cs`, `not_contains_cs`, `startswith_cs`, `not_startswith_cs`,
+  //     `endswith_cs`, `not_endswith_cs`, as `CASE_SENSITIVE_WHOLE_VALUE_OPERATORS`. Named
+  //     one by one rather than as "and their negations": the shorthand is how the eighth
+  //     operator went missing from this paragraph in the first place.
+  //   * `c8e3e8a` — `in_cs`, `not_in_cs`, as `CASE_SENSITIVE_MEMBERSHIP_OPERATORS`. These
+  //     escaped the first round for a classification reason, not a semantic one: `in_cs` is
+  //     a keyword operator (an exact-match `terms` query), so it routed through a different
+  //     branch of `get_query_field` whose fallback still landed on the analyzed field.
+  //
+  // Both constants live in `tql/src/opensearch/field_mappings.rs` and
+  // `src/tql/opensearch_components/field_mapping.py`. A note here naming only the first six
+  // would leave a reader correct about `contains_cs` and wrong about `in_cs`, silently —
+  // which is the exact failure the engines' own interim pin existed to prevent.
+  //
+  // That rule is NOT expressible in this package, and the reason is specific rather than a
+  // shrug: it keys on the MAPPING, not on the field type. The engines refuse only when there
+  // is no case-preserving form — a `text` field WITH a `.keyword` subfield translates fine,
+  // and that is the most common shape in ECS. This package's field model
+  // (`TqlValidationOptions.fieldTypes`, `TqlFieldSchema`) carries one `TqlFieldType` per
+  // name and nothing about analysis or multifields: `TqlFieldSchema.nested` is object
+  // children, not subfields. So `type === "text"` does not decide the question, and a check
+  // keyed on it would be a false positive on exactly the mapping shape that works.
+  //
+  // Dropping `text` from the eight `_cs` rows — the six below and `in_cs` / `not_in_cs`
+  // further down — would be that check by another name. It is left in on all eight.
+  // Closing this properly means teaching the schema about multifields, at which point the
+  // rule belongs in `OPERATOR_REQUIRED_FIELD_TYPES`'s caller rather than in the table.
+  //
+  // `tests/caseSensitiveOperatorAbsence.spec.ts` derives the engines' refusal set from their
+  // own sources and asserts this note names all of it — so a third `_cs` round cannot leave
+  // this paragraph quietly under-claiming the way the six-name version did.
   contains: ["text", "keyword"],
   not_contains: ["text", "keyword"],
   "!contains": ["text", "keyword"],
@@ -44,47 +132,93 @@ const c = {
   matches: ["text", "keyword"],
   not_matches: ["text", "keyword"],
   "!matches": ["text", "keyword"],
-  // Range
-  between: ["long", "integer", "double", "float", "date"],
-  not_between: ["long", "integer", "double", "float", "date"],
-  "!between": ["long", "integer", "double", "float", "date"],
-  in: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip"],
-  not_in: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip"],
-  "!in": ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip"],
+  // Range. Numeric and date, via the named constant — the transcribed list this replaces
+  // dropped the same five narrow widths `eq` did (`short`, `byte`, `half_float`,
+  // `scaled_float`, `unsigned_long`), so `port between [1, 1024]` on a `short` field warned.
+  // Python's `numeric_ops` carries `between` and covers `short` and `byte`; the other three
+  // widths have no arm at all in `_validate_simple_type_compatibility` and fall through its
+  // `else: return`, which allows every operator.
+  //
+  // `keyword` and `text` stay out, and that is a decision rather than an omission: Python's
+  // `keyword_ops` excludes `between` while including `gte`, which is the divergence pinned
+  // in `tests/collectionAndNullSemantics.spec.ts`.
+  between: g,
+  not_between: g,
+  "!between": g,
+  // Membership — the same set as `eq`, because `in` IS a disjunction of equalities and both
+  // evaluators implement it that way. The transcribed list this replaces omitted the five
+  // narrow numeric widths plus `nested`, `object` and `geo_point`.
+  //
+  // This is deliberately WIDER than Python's validator, which is already the standing stance
+  // here rather than a new one: `date_ops` and `boolean_ops` both omit `in`, so
+  // `_validate_simple_type_compatibility` refuses `f in ['2024-01-01','2024-01-02']` on a
+  // date field — while its own evaluator answers it and the cluster serves the DSL. That is
+  // the same validator-versus-evaluator disagreement already pinned for `keyword between`
+  // and `keyword is null`, and this table has always sided with the evaluator on it (`date`
+  // and `boolean` were in the transcribed list too). Widening to the remaining types applies
+  // the existing stance consistently; it does not take a new position.
+  in: i,
+  not_in: i,
+  "!in": i,
   in_cs: ["text", "keyword"],
   not_in_cs: ["text", "keyword"],
   "!in_cs": ["text", "keyword"],
-  // Existence (all types)
-  exists: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  not_exists: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  "!exists": ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  // Null checks (all types)
-  is: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  is_not: ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
-  "!is": ["text", "keyword", "long", "integer", "double", "float", "date", "boolean", "ip", "nested", "object", "geo_point"],
+  // Existence and null checks — ONE predicate, so ONE list.
+  //
+  // `field is null` now means the field HAS NO VALUE (absent OR explicitly null), which is
+  // exactly `field not exists`; `is not null` is its complement and exactly `exists`. A
+  // product-owner decision landed in both engines as a breaking change. An empty array `[]`
+  // is a PRESENT value and satisfies neither `is null` nor `not exists` — complementarity is
+  // the reason, since `exists` answers true for `[]` and no record may satisfy both sides.
+  //
+  // Sharing the constant is what keeps the four honest. As four separate transcriptions they
+  // had already drifted from the union by five types apiece, and nothing would have caught
+  // two of them drifting from each other.
+  exists: i,
+  not_exists: i,
+  "!exists": i,
+  is: i,
+  is_not: i,
+  "!is": i,
   // IP-specific operators
   cidr: ["ip"],
   not_cidr: ["ip"],
   "!cidr": ["ip"],
-  // Collection operators
-  any: ["nested", "object", "keyword", "text"],
-  all: ["nested", "object", "keyword", "text"],
-  none: ["nested", "object", "keyword", "text"],
-  not_any: ["nested", "object", "keyword", "text"],
-  not_all: ["nested", "object", "keyword", "text"],
-  not_none: ["nested", "object", "keyword", "text"],
-  "!any": ["nested", "object", "keyword", "text"],
-  "!all": ["nested", "object", "keyword", "text"],
-  "!none": ["nested", "object", "keyword", "text"]
-}, l = {
+  // Collection operators — every type, and that is the engines' rule rather than a shrug.
+  //
+  // NOTE these rows are not reachable from this file: the parser builds a `collection` node
+  // whose `condition` carries the default inner operator `eq`, so `any`/`all`/`none` never
+  // arrive at `validateComparison`. They are corrected rather than left wrong because a
+  // stale rule gets copied -- the identical restriction WAS live in
+  // `completionProvider.ts`, where it withheld `any` from every `ip` and `long` field, and
+  // that is where `tests/collectionAndNullSemantics.spec.ts` measures it.
+  //
+  // Two things changed under this table. Both evaluators now treat a SCALAR field as a
+  // one-element collection (Rust returned false for every scalar before `1fe0a9f`), and both
+  // iterate array-valued fields across the comparison surface. Neither is conditional on the
+  // mapping type: OpenSearch has no array type, so `related.ip`, `host.ip`, `tags` and
+  // `dns.answers` are `ip` / `keyword` / `object` fields that ECS guarantees hold arrays.
+  //
+  // Restricting these six to `nested | object | keyword | text` therefore described neither
+  // engine. `related.ip any ["10.0.0.1"]` is the ordinary case for an IP field, not an
+  // abuse of one.
+  any: i,
+  all: i,
+  none: i,
+  not_any: i,
+  not_all: i,
+  not_none: i,
+  "!any": i,
+  "!all": i,
+  "!none": i
+}, h = {
   cidr: ["ip"],
   not_cidr: ["ip"],
   "!cidr": ["ip"]
-}, u = {
+}, y = {
   eq: ["string", "number", "boolean"],
   ne: ["string", "number", "boolean"],
   "=": ["string", "number", "boolean"],
-  "==": ["string", "number", "boolean"],
   "!=": ["string", "number", "boolean"],
   eq_ci: ["string"],
   gt: ["number", "string"],
@@ -154,17 +288,17 @@ class b {
   options;
   errors;
   warnings;
-  constructor(e = {}) {
-    this.options = e, this.errors = [], this.warnings = [];
+  constructor(t = {}) {
+    this.options = t, this.errors = [], this.warnings = [];
   }
   /**
    * Validate a TQL query
    */
-  validate(e) {
-    if (this.errors = [], this.warnings = [], !e)
+  validate(t) {
+    if (this.errors = [], this.warnings = [], !t)
       return { valid: !0, errors: [], warnings: [] };
-    const t = g(e);
-    return this.errors.push(...t.errors), this.warnings.push(...t.warnings), t.ast && this.validateExpression(t.ast), {
+    const e = w(t);
+    return this.errors.push(...e.errors), this.warnings.push(...e.warnings), e.ast && this.validateExpression(e.ast), {
       valid: this.errors.length === 0,
       errors: this.errors,
       warnings: this.warnings
@@ -173,171 +307,276 @@ class b {
   /**
    * Validate an expression recursively
    */
-  validateExpression(e) {
-    switch (e.type) {
+  validateExpression(t) {
+    switch (t.type) {
       case "binary":
-        this.validateExpression(e.left), this.validateExpression(e.right);
+        this.validateExpression(t.left), this.validateExpression(t.right);
         break;
       case "unary":
-        this.validateExpression(e.operand);
+        this.validateExpression(t.operand);
         break;
       case "group":
-        this.validateExpression(e.expression);
+        this.validateExpression(t.expression);
         break;
       case "comparison":
-        this.validateComparison(e);
+        this.validateComparison(t);
+        break;
+      // `field ANY value`. The collection wrapper carries no validatable content of its
+      // own -- field, inner operator and value all live in `condition` -- but it must be
+      // walked explicitly. Falling through the switch would have made every collection
+      // query validate vacuously clean, which is the failure mode this node type was added
+      // out of, not into.
+      //
+      // The COLLECTION OPERATOR itself is deliberately not checked here. Every field type
+      // is compatible with it (see the note on `any` in OPERATOR_TYPE_COMPATIBILITY), so a
+      // check would be a code path that can never produce an answer -- and a mechanism with
+      // no reachable outcome reads as enforcement while enforcing nothing. The completion
+      // provider's copy of the table IS live, and is where the widened rule is observable.
+      //
+      // The OPERAND SHAPE is checked, though — see validateCollectionOperand.
+      case "collection":
+        this.validateCollectionOperand(t), this.validateExpression(t.condition);
         break;
     }
   }
+  /**
+   * `f any ['a','b']` is ill-typed. Say so, and name `in`.
+   *
+   * ## The rule, as both engines implement it
+   *
+   * `any` / `none` apply a comparison to each ELEMENT of an array-valued field. The operand
+   * is therefore a SCALAR: `f any 'admin'` asks whether some element equals `'admin'`. A
+   * LIST operand asks whether some single element equals the whole two-element list, which
+   * no scalar element can. `in` is already the membership operator, and is what the author
+   * meant.
+   *
+   * Both engines now refuse it -- `ab55587` in `tql/src/opensearch/query_builder.rs`
+   * (`build_collection_op`) and `_refuse_list_operand` in
+   * `src/tql/opensearch_components/query_converter.py` -- raising a type error whose
+   * `valid_operators` are `in` / `not in`. Before that it emitted `{"term": {"f": [..]}}`,
+   * which OpenSearch answers with HTTP 400 `[term] query does not support array of values`,
+   * failing the WHOLE search including every unrelated clause; the intermediate fix emitted
+   * `match_none`, which executed cleanly and excluded nothing, silently.
+   *
+   * ## Three arities, and only the middle one is new
+   *
+   * The engines do NOT test `is_array`. They unwrap a single-element list FIRST
+   * (`unwrap_single` in Rust, `len(value) == 1` in Python) and refuse only what is still a
+   * list. Measured against the live Python translator at `ab55587`:
+   *
+   * | Query              | Python translator                                    |
+   * |--------------------|------------------------------------------------------|
+   * | `f any 'admin'`    | `{"term": {"f": "admin"}}`                            |
+   * | `f any ['a']`      | `{"term": {"f": "a"}}` -- unwrapped, NOT refused      |
+   * | `f any ['a','b']`  | `TQLTypeError`, valid operators `in`, `not in`        |
+   *
+   * A naive `Array.isArray(value)` check would flag `f any ['a']`, which both engines
+   * translate perfectly well -- a red squiggle over a working query, which is the defect
+   * this parser keeps being fixed for. Hence `length >= 2`, and hence the two arities are
+   * tested separately in `tests/collectionListOperand.spec.ts`.
+   *
+   * The empty list is not handled here: `f any []` is already an `INVALID_VALUE` error from
+   * the parser (`tests/emptyValueList.spec.ts`), and Python does not even parse it
+   * (`TQLSyntaxError`). Reporting it twice would be noise.
+   *
+   * ## Why `ALL` is excluded, and why that is not an oversight
+   *
+   * `all` / `not_all` are answered by a Painless script that compares each element to
+   * `params.value`. A list operand there emits valid DSL that matches nothing -- which is
+   * what both in-memory evaluators also answer -- so both engines dispatch `all` BEFORE the
+   * refusal and leave it untouched. `f all ['a','b']` translating cleanly is a pinned
+   * negative case here, not a gap.
+   *
+   * Negation is irrelevant: in both engines the array check precedes the quantifier wrapper,
+   * so `not any` / `not none` refuse on the same footing as the positive spellings.
+   */
+  validateCollectionOperand(t) {
+    if (t.operator === "ALL")
+      return;
+    const e = t.condition;
+    if (e.type !== "comparison")
+      return;
+    const n = e.value;
+    if (!Array.isArray(n) || n.length < 2)
+      return;
+    const s = t.operator.toLowerCase(), r = t.negated ? `not ${s}` : s, l = t.field.name;
+    this.addError(
+      `'${r}' takes a single value and tests it against each element of '${l}'; it does not take a list.`,
+      n[0].start,
+      n[n.length - 1].end,
+      1,
+      1,
+      "TYPE_MISMATCH",
+      `Use \`in\` for membership: \`${l} in [...]\` (or \`${l} not in [...]\` to exclude).`
+    );
+  }
   /**
    * Validate a comparison expression
    */
-  validateComparison(e) {
-    const t = e.field.type === "field" ? e.field.name : "computed";
-    if (this.options.availableFields && this.options.strictMode && !this.options.availableFields.includes(t) && e.field.type === "field" && this.addWarning(
-      `Unknown field '${t}'`,
-      e.field.start,
-      e.field.end,
-      (e.field.type === "field", 1),
+  validateComparison(t) {
+    const e = t.field.type === "field" ? t.field.name : "computed";
+    if (this.options.availableFields && this.options.strictMode && !this.options.availableFields.includes(e) && t.field.type === "field" && this.addWarning(
+      `Unknown field '${e}'`,
+      t.field.start,
+      t.field.end,
+      (t.field.type === "field", 1),
       1,
       "UNKNOWN_FIELD",
-      `Did you mean: ${this.suggestField(t)}`
-    ), this.options.fieldTypes && e.field.type === "field") {
-      const o = this.options.fieldTypes[t];
-      if (o) {
-        const n = l[e.operator];
-        n && !n.includes(o) && this.addError(
-          `Operator '${e.operator}' requires field type ${n.join(" or ")}, but '${t}' is type '${o}'`,
-          e.start,
-          e.end,
+      `Did you mean: ${this.suggestField(e)}`
+    ), this.options.fieldTypes && t.field.type === "field") {
+      const n = this.options.fieldTypes[e];
+      if (n) {
+        const s = h[t.operator];
+        s && !s.includes(n) && this.addError(
+          `Operator '${t.operator}' requires field type ${s.join(" or ")}, but '${e}' is type '${n}'`,
+          t.start,
+          t.end,
           1,
           1,
           "TYPE_MISMATCH",
-          `Use '${e.operator}' only with ${n.join(" or ")} fields`
+          `Use '${t.operator}' only with ${s.join(" or ")} fields`
         );
       }
     }
-    if (this.options.fieldTypes && e.field.type === "field") {
-      const o = this.options.fieldTypes[t];
-      if (o) {
-        const n = c[e.operator];
-        !l[e.operator] && n && !n.includes(o) && this.addWarning(
-          `Operator '${e.operator}' may not work well with field type '${o}'`,
-          e.start,
-          e.end,
+    if (this.options.fieldTypes && t.field.type === "field") {
+      const n = this.options.fieldTypes[e];
+      if (n) {
+        const s = f[t.operator];
+        !h[t.operator] && s && !s.includes(n) && this.addWarning(
+          `Operator '${t.operator}' may not work well with field type '${n}'`,
+          t.start,
+          t.end,
           1,
           1,
           "TYPE_MISMATCH",
-          `Consider using a different operator for ${o} fields`
+          `Consider using a different operator for ${n} fields`
         );
       }
     }
-    if (!Array.isArray(e.value) && e.value.type === "literal") {
-      const o = u[e.operator];
-      o && !o.includes(e.value.valueType) && this.addWarning(
-        `Operator '${e.operator}' expects ${o.join(" or ")} value`,
-        e.value.start,
-        e.value.end,
+    if (!Array.isArray(t.value) && t.value.type === "literal") {
+      const n = y[t.operator];
+      n && !n.includes(t.value.valueType) && this.addWarning(
+        `Operator '${t.operator}' expects ${n.join(" or ")} value`,
+        t.value.start,
+        t.value.end,
         1,
         1,
         "TYPE_MISMATCH"
       );
     }
-    if ((e.operator === "regexp" || e.operator === "regex" || e.operator === "not_regexp" || e.operator === "not_regex" || e.operator === "matches" || e.operator === "not_matches") && !Array.isArray(e.value) && e.value.valueType === "string" && typeof e.value.value == "string")
-      try {
-        new RegExp(e.value.value);
-      } catch {
+    if ((t.operator === "regexp" || t.operator === "regex" || t.operator === "not_regexp" || t.operator === "not_regex" || t.operator === "matches" || t.operator === "not_matches") && !Array.isArray(t.value) && t.value.valueType === "string" && typeof t.value.value == "string") {
+      const n = Array.from(t.value.value).length;
+      if (n > c)
         this.addError(
-          `Invalid regular expression: ${e.value.value}`,
-          e.value.start,
-          e.value.end,
+          `Regex pattern is ${n} characters, which exceeds the maximum supported length of ${c}. The query cannot run as written.`,
+          t.value.start,
+          t.value.end,
           1,
           1,
           "INVALID_VALUE",
-          "Check the regex syntax"
+          "Split the pattern into several shorter alternations combined with OR, or use an `in [...]` list"
         );
-      }
+      else
+        try {
+          new RegExp(t.value.value);
+        } catch {
+          this.addError(
+            `Invalid regular expression: ${t.value.value}`,
+            t.value.start,
+            t.value.end,
+            1,
+            1,
+            "INVALID_VALUE",
+            "Check the regex syntax"
+          );
+        }
+    }
   }
   /**
    * Suggest a similar field name using Levenshtein distance
    */
-  suggestField(e) {
+  suggestField(t) {
     if (!this.options.availableFields || this.options.availableFields.length === 0)
       return "check available fields";
-    let t = this.options.availableFields[0], o = this.levenshteinDistance(e, t);
-    for (const n of this.options.availableFields) {
-      const i = this.levenshteinDistance(e, n);
-      i < o && (o = i, t = n);
+    let e = this.options.availableFields[0], n = this.levenshteinDistance(t, e);
+    for (const s of this.options.availableFields) {
+      const r = this.levenshteinDistance(t, s);
+      r < n && (n = r, e = s);
     }
-    return t;
+    return e;
   }
   /**
    * Calculate Levenshtein distance between two strings
    */
-  levenshteinDistance(e, t) {
-    const o = [];
-    for (let n = 0; n <= t.length; n++)
-      o[n] = [n];
-    for (let n = 0; n <= e.length; n++)
-      o[0][n] = n;
-    for (let n = 1; n <= t.length; n++)
-      for (let i = 1; i <= e.length; i++)
-        t.charAt(n - 1) === e.charAt(i - 1) ? o[n][i] = o[n - 1][i - 1] : o[n][i] = Math.min(
-          o[n - 1][i - 1] + 1,
-          o[n][i - 1] + 1,
-          o[n - 1][i] + 1
+  levenshteinDistance(t, e) {
+    const n = [];
+    for (let s = 0; s <= e.length; s++)
+      n[s] = [s];
+    for (let s = 0; s <= t.length; s++)
+      n[0][s] = s;
+    for (let s = 1; s <= e.length; s++)
+      for (let r = 1; r <= t.length; r++)
+        e.charAt(s - 1) === t.charAt(r - 1) ? n[s][r] = n[s - 1][r - 1] : n[s][r] = Math.min(
+          n[s - 1][r - 1] + 1,
+          n[s][r - 1] + 1,
+          n[s - 1][r] + 1
         );
-    return o[t.length][e.length];
+    return n[e.length][t.length];
   }
-  addError(e, t, o, n, i, r, a) {
+  addError(t, e, n, s, r, l, d) {
     this.errors.push({
-      message: e,
-      start: t,
-      end: o,
-      line: n,
-      column: i,
+      message: t,
+      start: e,
+      end: n,
+      line: s,
+      column: r,
       severity: "error",
-      code: r,
-      suggestion: a
+      code: l,
+      suggestion: d
     });
   }
-  addWarning(e, t, o, n, i, r, a) {
+  addWarning(t, e, n, s, r, l, d) {
     this.warnings.push({
-      message: e,
-      start: t,
-      end: o,
-      line: n,
-      column: i,
+      message: t,
+      start: e,
+      end: n,
+      line: s,
+      column: r,
       severity: "warning",
-      code: r,
-      suggestion: a
+      code: l,
+      suggestion: d
     });
   }
 }
-function d(s, e) {
-  return new b(e).validate(s);
+function _(o, t) {
+  return new b(t).validate(o);
 }
-function h(s) {
-  return d(s).valid;
+function m(o) {
+  return _(o).valid;
 }
-function y(s, e) {
-  const t = d(s, e);
-  return [...t.errors, ...t.warnings];
+function v(o, t) {
+  const e = _(o, t);
+  return [...e.errors, ...e.warnings];
 }
-function f(s) {
-  const e = [];
-  s.valid ? e.push("Query is valid") : e.push("Query has errors:");
-  for (const t of s.errors)
-    e.push(`  Error: ${t.message}`), t.suggestion && e.push(`    Suggestion: ${t.suggestion}`);
-  for (const t of s.warnings)
-    e.push(`  Warning: ${t.message}`), t.suggestion && e.push(`    Suggestion: ${t.suggestion}`);
-  return e.join(`
+function E(o) {
+  const t = [];
+  o.valid ? t.push("Query is valid") : t.push("Query has errors:");
+  for (const e of o.errors)
+    t.push(`  Error: ${e.message}`), e.suggestion && t.push(`    Suggestion: ${e.suggestion}`);
+  for (const e of o.warnings)
+    t.push(`  Warning: ${e.message}`), e.suggestion && t.push(`    Suggestion: ${e.suggestion}`);
+  return t.join(`
 `);
 }
 export {
+  i as ALL_FIELD_TYPES,
+  g as BETWEEN_FIELD_TYPES,
+  c as MAX_REGEX_PATTERN_LENGTH,
+  u as NUMERIC_FIELD_TYPES,
+  a as ORDERED_FIELD_TYPES,
   b as TqlValidator,
-  f as formatValidationResult,
-  y as getTqlIssues,
-  h as isValidTqlSyntax,
-  d as validateTql
+  E as formatValidationResult,
+  v as getTqlIssues,
+  m as isValidTqlSyntax,
+  _ as validateTql
 };