fix(elasticsearch): support fieldMultiValueLeniency for array columns

[nktnet1]

Description

Enable fieldMultiValueLeniency.

Note that with this option enabled, for array fields, only one value is returned. This is a limitation outlined here:

• https://www.elastic.co/docs/reference/query-languages/sql/sql-limitations#array-type-of-fields

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Performance improvement
• Test addition or update

Related Issue

Resolves #722

Changes Made

• enable fieldMultiValueLeniency

Testing

• I have tested this locally
• I have added/updated tests
• All existing tests pass (for elastic search)

Test Environment

• LibreDB Studio Version: 0.15.0
• Browser: Zen
• OS: MacOS
• Node.js/Bun Version: Bun v1.0
• Database Type: Elastic Search

Checklist

• My code follows the project's code style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cevheri]

Verified against the pinned images, not just the fixtures, and it holds. On Elasticsearch 9.1.4 SELECT tags FROM arrprobe is a 400 without the option and 200 with it, returning the first value in source order.
Paging is safe too: with 1200 documents the cursor carries the leniency, so page two still answers 200 from a cursor-only body.

Scoping it to Elasticsearch is right, and now measured: OpenSearch 3.8.0 returns the whole array for the same index with no error, so the fork has nothing to fix here.

Two things before it lands.

• Docs belong in the same PR in this repo: docs/providers/elasticsearch.md section 5.4 is the home for it, and it should carry the sharp part of the measurement, SELECT tags FROM arrprobe WHERE tags = 'alpha' matches every row and then displays zebra, so the value that matched is not the value shown. A line in opensearch.md 5.4 for the asymmetry would help too.

• Second, the OpenSearch suite only ever reads query out of a sent body, so nothing would fail if this option later reached the fork. One exact-body assertion there pins it.

Minor: the neighbouring spec members state every disagreement outright (aliasKey: null, totalKey: null), so a required boolean with false on opensearch would fit that table and drop the === true at the send site.

[cevheri]

commented