Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@cipherstash/eql@3.0.1

Patch Changes

• a8ec17c: The encrypted-JSON domains are renamed for a consistent public.eql_v3_json family, and a new ciphertext-only storage domain is added. The bare name public.eql_v3_json is now a storage-only domain (a single opaque ciphertext, {v,i,c} envelope, no index terms — the JSON analogue of public.eql_v3_boolean, for encrypt-at-rest with no server-side searchability). The searchable SteVec document that previously held the bare public.eql_v3_json name is renamed to public.eql_v3_json_search; its supporting domains follow: public.eql_v3_jsonb_entry → public.eql_v3_json_entry, and the containment needle eql_v3.query_jsonb → eql_v3.query_json. This makes the JSON family follow the same convention as every scalar family — the bare family name is the storage-only domain and a suffix (_search, mirroring text's _search) marks the searchable variant. Reach for public.eql_v3_json_search when you need containment/field queries over encrypted JSON (@>, path access) and public.eql_v3_json when you only need to store and round-trip an encrypted JSON value. Callers on the previous names must update column declarations and query casts (WHERE doc @> $1::eql_v3.query_json); the bindings, DomainPayload/QueryPayload parse names, and published JSON Schema file names all move to the new names.
• 18d58e7: Text bloom fuzzy match is renamed to @@ / eql_v3.matches — it is n-gram token matching, not containment. On the text match/search domains (public.eql_v3_text_match, public.eql_v3_text_search, public.eql_v3_text_search_ore) the fuzzy match was previously spelled with the containment operators @> / <@, backed by eql_v3.contains / eql_v3.contained_by. That promised substring/containment semantics the operation does not provide: it is array containment over two bloom filters built from the downcased 3-gram token set — a probabilistic, order- and multiplicity-insensitive, one-sided match (a true may be a false positive; a false never is). The match is now a single directional operator @@ backed by eql_v3.matches (WHERE col @@ $1::public.eql_v3_text_match), and the reverse contained_by direction is dropped. @> and <@ now raise "operator not supported" on the text match domains. The functional GIN index recipe is unchanged (GIN (eql_v3.match_term(col))): col @@ $1 inlines through match_term to the same array-containment the index supports. Genuine JSON containment (public.eql_v3_json_search @>/<@, eql_v3.ste_vec_contains) keeps the containment vocabulary and is unaffected. This is the SQL-layer counterpart of the SDK's contains() → matches() rename; callers or SDKs emitting eql_v3.contains(col, …) / col @> $1 for text match must switch to eql_v3.matches(col, …) / col @@ $1 in lockstep. See upgrade note U-008.