kura_ets_query (kura_ets v0.0.1)
View SourcePlan 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
-spec run(atom(), kura_ets_dialect:plan()) -> dynamic().