docs(stack): EQL v3 Supabase integration design spec#546
Conversation
Design for EQL v3 on Supabase at parity with the v2 adapter, using native eql_v3.* domain columns. v3 mirrors v2's query mechanism (direct EQL operators, same operator-visibility caveat and Exposed-schemas requirement); only the column types and internal encoding differ. Covers: the encryptedSupabaseV3 adapter + dialect fork, the opclass-stripped v3 Supabase SQL bundle and installer/grants path, the text_search equality CHECK operand fix, and the test/docs/release plan.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…pter The v2 query mechanism (direct EQL operators over PostgREST) unchanged; EncryptedQueryBuilderImpl gains narrow protected seams whose defaults preserve the v2 behaviour byte-for-byte, and a v3 subclass overrides them: - column recognition + property↔DB name resolution via buildColumnKeyMap (filters, mutations, aliased select casts `prop:db::jsonb`) - raw jsonb mutation payloads (no eql_v2 composite wrap) - full-envelope filter operands: every eql_v3.* domain CHECK requires the storage keys (v/i/c + index terms) and the SQL operators coerce their jsonb operand into the domain, so a narrowed encryptQuery term (c?: never) fails 23514 on EVERY domain — not just text_search as the design spec assumed. All operands go through encrypt() instead. - like/ilike on encrypted columns → PostgREST cs (bloom @>); the domains define no LIKE operator - Date reconstruction from cast_as on decrypted rows - capability validation: filters on storage-only columns or unsupported query types throw typed + runtime errors Wire-encoding unit tests (mock encryption + supabase clients) cover both dialects, including v2 regression pins for the seams. Part of CIP-3300; design spec in PR #546.
1 participant
Summary
Adds the design spec for EQL v3 on Supabase, at parity with the existing v2
encryptedSupabaseadapter, using nativeeql_v3.*domain columns.Core principle: v3 mirrors v2 exactly — same query mechanism (direct EQL operators), same operator-visibility caveat and Exposed-schemas requirement, same install/permissions story. Only the column types (v2 composite
eql_v2_encrypted→ per-domaineql_v3.*) and internal encoding differ. An earlier draft's separate v3 query path (function pattern / generated columns / RPC) was dropped: it tried to eliminate a caveat v2 already lives with, and didn't even help the ORE-range case it was invoked for.What the spec covers
encryptedSupabaseV3+ a narrowdialectfork ofEncryptedQueryBuilderImpl(column recognition, property↔DB name, mutation/query-term encoding,reconstructRow, thetext_searchequality operand).SUPABASE_PERMISSIONS_SQLkeyed toeql_v3, and the manual Exposed-schemas step.text_searchdomain CHECK (hm+ob+bf) rejects anhm-only equality operand; fixed by building the operand from the full envelope.Date-column round-trip and CS_*-gated ORE range), type-level tests, doc updates (incl. re-creating the deletedsupabase-sdk.md), changeset.Notes for reviewers
ee56fb68add /def9f4bddelete ofsupabase-sdk.md) are verified against the tree.text_searchoperand via a realencryptQuery).feat/eql-v3-text-search-schema— this PR targets that branch, so the diff is the spec only.