kura_ets_query (kura_ets v0.0.1)

View Source

Plan interpreter for the ETS backend. Executes the {kura_ets, Plan} terms emitted by kura_ets_dialect against the pool's ETS tables and returns pgo-shaped results (#{command, rows, num_rows}).

Storage model

One set table per source table. Objects are {Key, Row} where Row is a map of dumped field values (as produced by kura's type system on the write path) and Key is the primary-key value — a bare value for single-column keys, a tuple for composite keys, or a unique reference when no primary key can be derived from the schema.

Missing columns are materialized as null at insert (with schema defaults applied first), mirroring what a SQL backend would return, so is_nil conditions and kura_db:load_row/2 behave identically.

Filtering

Queries are evaluated with a plain scan-and-filter over the table (ets:tab2list/1), not with match specifications: kura's where grammar (like/ilike, composite in, between, nested and/or/not) maps poorly onto match-spec guards, and for the in-memory datasets this backend targets a scan is fast enough and far simpler to verify. One exception: when the top-level wheres pin every primary-key column with an equality, the row is fetched with ets:lookup/2 (the storage key is the primary key), making point reads O(1) — the cache-aside hot path. Comparison values are passed through kura_types:dump/2 when the schema declares a type for the field, so they compare against the stored (dumped) representation the same way SQL params are encoded by a database client.

SQL null semantics are approximated: a comparison against a null (undefined/null) field value is false, except for the explicit is_nil / is_not_nil conditions.

Unsupported constructs (joins, group_by, having, CTEs, combinations, subqueries, fragments, matches, locks, prefix multitenancy) yield {error, {kura_ets_unsupported, What}}.

Summary

Functions

run(Pool, Plan)

-spec run(atom(), kura_ets_dialect:plan()) -> dynamic().