@lde/search-typesense 0.29.4 → 0.31.0

package/dist/collection-definition.js

@@ -317,7 +317,7 @@ function nestedFields(prefix, reference, nestedType, schema, defaultLocale, with
                 type: boundaryArray ? 'string[]' : 'string',
                 index: false,
                 optional: true,
-            }, ...nestedIdentityFields(prefix, field, schema));
+            }, ...nestedIdentityFields(prefix, field, schema, flattensToArray));
             continue;
         }
         if (deeper !== undefined) {
@@ -327,7 +327,7 @@ function nestedFields(prefix, reference, nestedType, schema, defaultLocale, with
             // an engine welds conditions on an entry's LEAF fields only. Its
             // identity companion is that leaf, so it sits beside the object rather
             // than inside it.
-            ...nestedIdentityFields(prefix, field, schema));
+            ...nestedIdentityFields(prefix, field, schema, flattensToArray));
             continue;
         }
         children.push(...nestedLeafFields(prefix, field, defaultLocale, flattensToArray));
@@ -384,7 +384,7 @@ function identityCompanionFields(field, schema) {
 /** The identity companion of a nested field that stores an object: a flat leaf
  *  beside it, holding the ids a filter welds on. Empty for a nested field that
  *  declares no query Role, which needs none. */
-function nestedIdentityFields(prefix, field, schema) {
+function nestedIdentityFields(prefix, field, schema, flattensToArray) {
     const names = physicalFields(field, schema);
     if (names.identity === undefined) {
         return [];
@@ -392,11 +392,23 @@ function nestedIdentityFields(prefix, field, schema) {
     return [
         {
             name: nestedFieldName(prefix, names.identity),
-            // Always a list, whatever the enclosing reference's arity: the projection
-            // writes it with `setArray`, and an indexed field's declared type is
-            // checked against what is stored – a `string` here rejects every
-            // document carrying such an edge, at import.
-            type: 'string[]',
+            // Typed by what the PATH yields across the document, exactly as the `id`
+            // beside it is, and by the same two routes every other declaration here
+            // uses: an `object[]` ancestor multiplying the entries, or the field's
+            // own `array` making each entry hold a list. A weldable leaf is
+            // single-valued (ADR 26), so a companion that a weld names contributes
+            // one id per entry – but a multi-valued reference reached through a
+            // locally-nested Root Type is not weldable and still harvests a list.
+            // Getting either route wrong rejects the document at import: Typesense
+            // enforces the declared arity wherever nothing widens the path.
+            // `filterable` is the condition because it is what the projection writes
+            // a single id under, not because it decides the split: `tuplesOf` splits
+            // the identity field whatever Role earned it. A `facetable`-only
+            // companion is declared a list, which is what a facet reads and what the
+            // projection writes for it.
+            type: flattensToArray || field.array === true || field.filterable !== true
+                ? 'string[]'
+                : 'string',
             index: true,
             optional: true,
         },
@@ -458,6 +470,10 @@ function nestedLeafFields(prefix, field, defaultLocale, flattensToArray) {
     // `object[]` flattens it into one. `typesenseValueType` honours `array` only
     // for the string-shaped kinds, so a multi-valued nested `integer` would
     // otherwise be declared scalar and rejected at import.
+    //
+    // A weldable leaf of a Reference Type is single-valued (ADR 26), but that
+    // narrows nothing here: this same path declares the fields of the Root Type a
+    // `local` lookup nests, where `array` and `filterable` may legitimately meet.
     const storesAList = flattensToArray || field.array === true;
     fields.push({
         name: nestedFieldName(prefix, field.name),
@@ -498,8 +514,11 @@ function arrayValueType(type) {
             return 'float[]';
         case 'bool':
             return 'bool[]';
-        // Already a list: a multi-valued declaration under a multi-valued ancestor
-        // flattens no further.
+        // Already a list, and reachable even though a weldable leaf of a Reference
+        // Type is single-valued (ADR 26): this path also declares the fields of the
+        // Root Type a `local` lookup nests, and `searchSchema` constrains only
+        // Reference Types. A root keyword may be `array` and `filterable` at once –
+        // an ordinary facet – so flattening it must widen no further.
         case 'string[]':
             return 'string[]';
     }

package/dist/search.js

@@ -678,9 +678,11 @@ function localizedValue(flat, field) {
  * Rebuild a surfaced inline reference from the nested object(s) the engine
  * stored: one {@link NestedDocument} per referent, each carrying its Reference
  * Type’s own output fields – so a multi-valued reference keeps every referent’s
- * values grouped rather than smeared across parallel arrays. `id` is carried
- * only when the referent had one; a blank-node referent nests without it, since
- * a nested document is read, not addressed. A nested reference type may itself
+ * values grouped rather than smeared across parallel arrays. An entry of a
+ * Reference Type carries no `id` – a nested document is read, not addressed –
+ * so the one read back here belongs to a {@link ReferenceStrategy.local local}
+ * lookup's Root Type, whose collection files it under that key. A nested
+ * reference type may itself
  * surface an inline reference, which recurses through {@link reconstructDocument}.
  */
 function nestedValue(raw, field, referenceType, labels, schema, children) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lde/search-typesense",
-  "version": "0.29.4",
+  "version": "0.31.0",
   "description": "Typesense implementation of the @lde/search SearchEngine port: collection-schema builder, query compiler, label-resolving result reconstruction, and blue/green index lifecycle. Engine-specific (Typesense) but domain-agnostic.",
   "repository": {
     "url": "git+https://github.com/ldelements/lde.git",
@@ -25,7 +25,7 @@
     "!**/*.tsbuildinfo"
   ],
   "dependencies": {
-    "@lde/search": "^0.24.4",
+    "@lde/search": "^0.26.0",
     "@lde/text-normalization": "^0.1.2",
     "tslib": "^2.3.0",
     "typesense": "^3.0.6"