gem-hunter
主要言語: TypeScript
A native SQLite + Zod document store for Bun — Zod is the schema, bun:sqlite is the engine, no migrations and no ORM.
A native SQLite + Zod document-store library for Bun. Zod is the gatekeeper;
SQLite (bun:sqlite) is the synchronous, in-process engine. No migrations, no ORM —
the shape lives in Zod, the rows live in SQLite.
(id TEXT PRIMARY KEY, doc TEXT NOT NULL). The
shape lives in Zod, so there are no migrations — old rows read forward via schema
defaults, because every non-identity field declares a .default(...).json_extract expression indexes for declared index fields; filters compile to
matching predicates.bun:sqlite, synchronous, in-process. Native API, a real typed where-clause,
transactions, count, and batch operations.Batched populate is the default join API:
findByIds(ids) — one IN query, gated and deduped.populate(parents, foreignKey, target, as) — a resolver over findByIds that
dedups ids (each referenced doc is parsed once) and emits null for missing refs.ref(prefix) — a schema helper so references are typed and validated at the gate.@binaryplease/zodstore is a Bun-native library. Zod is a peer dependency, so
install both:
bun add @binaryplease/zodstore zod
It imports bun:sqlite, so it runs under Bun only — not Node.
The package ships TypeScript sources rather than a compiled bundle: exports points
at src/index.ts, which Bun imports directly and which is also where the types come
from. There is no build step to run and no dist/ to configure.
import { z } from "zod"; import { createStore, populate, ref } from "@binaryplease/zodstore"; // Schemas are the single source of truth. Every non-identity field declares a // default so old rows read forward without migration. const UserSchema = z.object({ id: ref("user"), // identity — required, fails loudly if absent name: z.string().default(""), age: z.number().default(0), active: z.boolean().default(true), nickname: z.string().nullable().default(null), }); const PostSchema = z.object({ id: ref("post"), authorId: ref("user"), // typed, validated foreign key title: z.string().default(""), views: z.number().default(0), }); const store = createStore({ path: "data.sqlite" }); // omit path for an in-memory store const users = store.collection("users", UserSchema, { indexes: ["age", { fields: ["active"], unique: false }], }); const posts = store.collection("posts", PostSchema, { indexes: ["authorId"] }); users.insert({ id: "user_alice", name: "Alice", age: 30 }); posts.insert({ id: "post_1", authorId: "user_alice", title: "Hello" });
users.get("user_alice"); // → full document, or null users.find({ where: { active: true, age: { gte: 18, lt: 65 } }, orderBy: { field: "age", direction: "desc" }, limit: 20, offset: 0, }); users.findOne({ where: { name: "Alice" } }); users.count({ active: true }); users.validate(); // → [{ id, error }] for rows the schema now rejects users.update("user_alice", { age: 31 }); // shallow-merge + re-validate; null if absent users.replace("user_alice", { id: "user_alice", name: "Alice II" }); users.upsert({ id: "user_bob", name: "Bob" }); users.delete("user_alice"); // → boolean users.deleteMany({ active: false }); // → number removed
Where-clause operators: eq, ne, gt, gte, lt, lte, in, notIn, contains,
startsWith, endsWith, like, isNull. A bare value is shorthand for eq. null
(or { eq: null }) compiles to IS NULL; { ne: null } / { isNull: false } to
IS NOT NULL. A Date operand binds as the ISO string it is stored as, so a
range query over a dateParser field — { at: { gt: new Date("2026-01-01") } } —
and an orderBy over it answer chronologically; an invalid Date, or one
outside years 0000–9999 (whose expanded ISO form would not order against stored
timestamps — dateParser refuses to store one either), is refused naming the
operator or field at fault.
An operand that cannot be compared is refused, not answered with an empty result. A
filter that quietly matches nothing reads exactly like a truthful "no rows", so the
operand is named instead: NaN (which is what Number(badQueryParam) produces, and which
binds as SQL NULL), a non-boolean isNull ("false" is what ?isNull=false yields
before anything parses it, and it used to select the rows it was written to exclude), a
null operand to gt/gte/lt/lte (a range comparison against no value has no
answer — isNull or eq: null is the spelling that does), and a non-string operand to
contains/startsWith/endsWith/like (a pattern is text; LIKE NULL is NULL for
every row). Infinity and -Infinity
pass: they bind as numbers and order against every stored value, so { age: { lt: Infinity } } is the "any number" filter it looks like.
A row with no value is excluded from the named set, not from the answer. ne and
notIn are total over the nullable domain: a null is not the value you named, so it
comes back.
users.insert({ id: "user_1", nickname: "mine" }); users.insert({ id: "user_2", nickname: null }); users.find({ where: { nickname: { ne: "mine" } } }); // → [user_2] users.find({ where: { nickname: { notIn: ["mine"] } } }); // → [user_2] users.deleteMany({ nickname: { ne: "keep" } }); // removes both, not just user_1
This is not what raw SQL does — NULL <> 'mine' and NULL NOT IN ('mine') are both
unknown, which a WHERE drops — so the compiled predicate names the null case
explicitly ((expr IS NULL OR expr <> ?)). Until it did, the null-valued rows vanished
from every exclusion filter and survived every deleteMany built on one (F042). Two
consequences of that, both deliberate:
null and an absent key are the same thing here. json_extract returns SQL
NULL for a JSON null and for a key that is not in the document, so eq: null,
isNull: true, ne and notIn cannot tell them apart and do not try. A field added by
an extended schema reads as absent on every row written before it existed, and reads as
null under these operators — see
Forward compatibility.null inside an in/notIn list names that same "no value". It is a member of
the set rather than a bound parameter nothing can equal, so in: [null] means
eq: null, notIn: [null] means ne: null, and notIn: ["mine", null] returns the
rows that are neither "mine" nor unset. The two operators are exact complements of one
another at every list shape.eq: null, ne: null and isNull are unchanged. NOT is still SQL's NOT over whatever
it wraps — see OR and NOT.
A condition whose value is undefined matches nothing. Filters get built from state
that may not be loaded yet, and the alternative — dropping the condition — turns a filter
into its opposite:
const currentUser: string | undefined = undefined; // session not loaded yet cases.find({ where: { assignee: currentUser } }); // → [] , not every case cases.count({ assignee: currentUser }); // → 0 cases.deleteMany({ assignee: currentUser }); // → 0 rows deleted, not all of them
The rule holds wherever the value goes missing: in an operator object
({ age: { gte: undefined } }), beside a live sibling ({ status: "open", assignee: undefined } matches nothing rather than every open case), and in an operator object that
names no operator at all:
const minimumAge: number | undefined = undefined; // the facet is cleared // the idiomatic optional filter — `{ age: {} }` when the bound is not supplied users.find({ where: { age: { ...(minimumAge !== undefined && { gte: minimumAge }) } } }); // → [] , the same answer as `{ age: { gte: undefined } }`
A gap can never be negated into a match. A clause carrying a missing value anywhere
below it compiles to "no rows" under NOT rather than being negated, at any depth:
// "delete everything except mine and the unassigned" — the retention shape cases.deleteMany({ NOT: { OR: [{ assignee: currentUser }, { assignee: null }] } }); // → 0 rows deleted while `currentUser` is unset, not "everything except the unassigned"
That case is worth stating separately because the disjunction is still a usable filter in
positive position — OR: [{ assignee: currentUser }, { assignee: null }] returns the
unassigned rows, and keeping that is deliberate. Negation inverts it: the branch that
narrowed the disjunction widens its complement by exactly the rows the missing condition
existed to protect. So whether a clause is usable and whether it is safe to negate are two
different questions, and NOT asks the stricter one. An explicit OR: [] decided "no
rows" with nothing missing, so NOT: { OR: [] } still matches every row.
To mean "no filter", say so: omit where, or pass {}. Only a clause that names no key
at all matches everything, which is what keeps deleteMany({}) meaningful.
To make a condition genuinely optional, leave the key out rather than setting it to
undefined:
const where = { status: "open", ...(assignee !== undefined && { assignee }) };
contains, startsWith, and endsWith escape their operand: % and _ are
ordinary characters in names, paths, and case references, and a search box that turns
% into a full-collection scan is a cheap way to make a server unresponsive.
users.find({ where: { name: { contains: "50%" } } }); // matches a literal "50%" users.find({ where: { name: { startsWith: "Al" } } });
like is the raw escape hatch and means what SQL means — the operand is the pattern,
wildcards and all. It compiles with ESCAPE '\', so an expert can still match a literal:
users.find({ where: { name: { like: "A%" } } }); // wildcard, as written users.find({ where: { name: { like: "%\\%%" } } }); // a literal "%" anywhere users.find({ where: { name: { like: "C:\\\\%" } } }); // a literal backslash, doubled
Because \ is the escape character, a literal backslash in a like pattern must be
doubled — an undoubled one escapes the character after it. contains, startsWith,
and endsWith do that for you; only the raw like operand is yours to escape.
None of these can use an index — a json_extract expression index serves equality and
range, and a leading-wildcard LIKE cannot use one at all. A substring filter scans, so
pair it with a limit on a large collection.
Anywhere a field is named — where, orderBy, and indexes — a dotted path into a
nested object works and is typed, up to three levels (a, a.b, a.b.c). A typo is a
compile error rather than a clause that silently matches nothing:
const PlaceSchema = z.object({ id: ref("place"), address: z .object({ city: z.string().default(""), geo: z.object({ zone: z.string().default("") }).default({ zone: "" }), }) .default({ city: "", geo: { zone: "" } }), }); const places = store.collection("places", PlaceSchema, { indexes: ["address.city"] }); places.find({ where: { "address.city": "Berlin", "address.geo.zone": { in: ["east"] } }, orderBy: { field: "address.city" }, });
The three-level bound is a compile-time budget, not a runtime one: deeper paths still
work through compileWhere/jsonExtract directly, they are simply not offered by the
typed surface, where unbounded recursion would blow TypeScript's instantiation limit.
An index is named after its field list alone — idx_<table>_<fields>, with a literal
_ doubled, a . written _dot_ and _and_ between two fields, so no two field lists
can produce one name. ["status"] is idx_notes_status; ["address.city"] is
idx_places_address_dot_city. The name is a pure function of the fields, so reopening a
collection with a declaration it already carries creates nothing. An index name is
scoped to the database rather than to one table, so on the rare shapes where two
collections derive onto the same name the open throws instead of quietly creating
nothing.
unique is deliberately not part of the name, so declaring the same fields once
non-unique and once unique is a redefinition, and it throws:
store.collection("things", schema, { indexes: ["email"] }); store.collection("things", schema, { indexes: [{ fields: ["email"], unique: true }] }); // throws: index "idx_things_email" over (email) already exists as a non-unique index … // Run DROP INDEX "main"."idx_things_email" and reopen if the change is intended.
Dropping a UNIQUE index takes away a constraint the application may still believe it
has, and adding one can fail against rows already stored; neither is decided quietly on
the caller's behalf. An index a version up to 0.4.2 wrote under the older, lossy name
is adopted on the next open — recreated under the current name, then dropped — so an
existing file ends up with one index per declaration and no migration to run.
Sibling keys of a where are joined with AND. Two reserved keys combine clauses
instead of naming a field, and they nest:
users.find({ where: { active: true, OR: [{ nickname: "mine" }, { nickname: null }] }, orderBy: { field: "age", direction: "desc" }, limit: 20, }); users.find({ where: { NOT: { OR: [{ age: { lt: 30 } }, { age: { gt: 40 } }] } } });
The orderBy and limit above apply across the whole union — the property two find()
calls merged in JavaScript cannot give you, because you cannot page a union assembled
after the fact.
A combinator fails closed. An empty OR: [] matches nothing, as an empty in does,
and so does a branch that carries no condition:
const currentUser: string | undefined = undefined; // session not loaded yet cases.find({ where: { OR: [{ assignee: currentUser }, { assignee: null }] } }); // → the unassigned rows only. The empty branch matches nothing rather than everything.
An empty NOT: {} matches nothing for the same reason, by the other route: it negates a
clause that matches everything.
NOT is SQL's NOT, with SQL's three-valued logic: NOT { name: "Ann" } does not match
a row whose name is null, because null = 'Ann' is unknown rather than false. Say
{ OR: [{ NOT: { name: "Ann" } }, { name: null }] } when you want the nulls too.
The keys are uppercase so they cannot be mistaken for fields, and store.collection(...)
refuses an object schema carrying a field named OR or NOT — including one under a
wrapper that hides its .shape, such as .transform(), .pipe(), .brand() or
.default(), and on both sides of a .pipe().
That guard is a strong default rather than a proof, so do not name a field OR or
NOT. Two cases are left: a .transform() that adds or renames a field declares its
output in a function body, which no reader can see into, and a schema whose fields are not
one readable shape — a union of object schemas, an intersection — contributes no names and
only reaches a collection under { enforceDefaults: false }
(see Forward compatibility). In both, the field
names are yours to keep clear of these two.
A where is a nested, JSON-shaped structure, and it is a plain TypeScript type rather
than a Zod schema — the deliberate in-process exception to Zod owning every shape,
because a where is assembled from already-validated input. Never pass an unvalidated request
body as where — parse it into the shape your handler intends first.
A find() with no limit selects every matching row and parses each one through Zod
into memory. That read is legitimate — an export job wants every row — but it should be
chosen, not defaulted into, so it is capped at maxRows (default 10_000) and
throws rather than truncates when the cap is exceeded: a silently truncated result
is a wrong answer.
createStore({ maxRows: 50_000 }); // raise it createStore({ maxRows: null }); // disable it users.find({ limit: 100, offset: 0 }); // an explicit bound is the caller's own // otherwise: find() on "users" returned more than maxRows (10000). Pass an explicit // limit, paginate, or raise/disable maxRows on the store.
Reads re-parse, so a schema change that is not an added defaulted field — tightening a type, narrowing an enum — can strand a row written under the old schema. The default policy is to throw, naming the row:
Collection "docs": stored row "p_2" does not match the current schema. …
The blast radius is that row, not the collection. Two ways past it:
store.collection("docs", Schema, { onParseError: "skip" }); // find()/findByIds() omit the row, get() returns null, findOne() steps over it // to the first readable match. The row is still there. store.collection("docs", Schema).validate(); // → [{ id: "p_2", error: ZodError }] — reads only, throws nothing, streams the table.
validate() is the repair primitive: it turns "the collection is broken" into a list of
ids to act on, without dropping to store.database and hand-written SQL.
"skip" is a read-for-repair mode, not a paging mode. The filter runs after SQL
has applied LIMIT, so a page containing a skipped row comes back short:
// rows p_1 (stale), p_2, p_3 under { onParseError: "skip" } docs.find(); // → [p_2, p_3] docs.find({ limit: 2 }); // → [p_2] ← a short page, not an error docs.findOne(); // → p_2 ← steps over p_1 to the first readable match docs.count(); // → 3 ← count() answers from SQL, Zod uncalled
The short page is a deliberate cost: limit/offset page over stored rows, and paging
over readable rows instead would make every page's offset require parsing the whole
table ahead of it. findOne() is the exception, because there is no page to keep
consistent — it streams to the first readable match, so a null still means "no match"
rather than "the first match was skipped".
Use it to read past damage while validate() tells you what to repair, then go back to
"throw". Writes never skip: update() on a row whose stored JSON is malformed throws,
naming the collection and the row, whatever the policy says.
const allPosts = posts.find(); const withAuthors = populate(allPosts, "authorId", users, "author"); // withAuthors[i].author is a fully-parsed user document, or null for a missing ref. users.findByIds(["user_alice", "user_bob", "user_alice"]); // deduped, order-preserving
populate resolves every distinct reference in a single findByIds query, so each
target document is fetched and parsed exactly once. Missing references become an
explicit null key, never a dropped property: nullish properties are emitted, so a
caller always sees the full shape.
store.transaction(() => { users.insert({ id: "user_carol" }); posts.insert({ id: "post_2", authorId: "user_carol" }); }); // committed on return, rolled back if the body throws users.insertMany([{ id: "user_d" }, { id: "user_e" }]); // atomic batch insert
store.transaction covers the connection it was called on and no other. A callback
that also writes through a collection of a different store is only half inside a
transaction: the other store's write commits on its own statement, and a throw rolls
back this half while leaving that one behind. There is no ordering of the two writes
that makes them atomic — reverse them and the surviving row is the other one.
transactionAcross is the primitive for work that spans two files. It attaches every
store's database to a single connection, so one transaction covers all of them:
const orders = createStore({ path: "orders.sqlite" }); const inventory = createStore({ path: "inventory.sqlite" }); transactionAcross([orders, inventory], ([ordersTx, inventoryTx]) => { inventoryTx.collection("stockLevels", StockLevelSchema).update("stk_widget", { onHand: 41 }); ordersTx.collection("orders", OrderSchema).insert({ id: "ord_1" }); }); // both files committed on return, both rolled back if the body throws
The callback gets one handle per store, in the order the stores were given, and only
those handles are inside the transaction. A collection opened on the outer orders
or inventory object writes on that store's own connection — it does not get to do so
quietly, because the transaction holds the write lock on every file it spans, so such a
write waits out its busyTimeoutMs and then throws database is locked. The handles
stop working once the transaction returns.
The limit, because it is part of what is being promised. SQLite commits attached databases atomically only when the journal mode is not WAL (
lang_attach.html) — and WAL is this library's default. Under WAL each file commits separately, so the error path is closed (a throw rolls every file back, which is the common case and the reason this exists) but the crash window is not: a process or machine that dies between two file commits leaves the earlier file committed and the later one not.Order the writes so that window fails in the direction you can live with, or open every store with a
journalModeother than"WAL", where SQLite's master journal makes the multi-file commit atomic outright. Every store: an attached database keeps the journal mode its own header says, and the weakest member decides the commit.
What it refuses, all before anything is opened:
| Refused | Why |
|---|---|
| An empty list | A store left out is a write outside the transaction. |
A store createStore did not open |
The file behind it is unknown, so it cannot be attached. |
| An in-memory store, in any position | ATTACH ':memory:' opens a second, empty database rather than reaching the store's — every write would land there and vanish at close. |
| The same file twice (symlinks resolved) | One file attached twice is two writers on one connection, which deadlocks against itself. |
| More than 11 stores | SQLITE_LIMIT_ATTACHED is 10 and one store is the connection's own main. |
A set whose journalModes disagree |
The mixed set would silently give every file WAL's guarantee, including to a caller who took the escape hatch above. |
The transaction runs on a connection of its own, under BEGIN IMMEDIATE, so it takes
every write lock up front and contention fails before anything is written rather than
halfway through. busy_timeout is per-connection, so that wait is stores[0]'s
busyTimeoutMs; a write attempted through an outer store while the transaction is
open waits out that store's own.
store.checkpoint(); // PASSIVE — what SQLite's auto-checkpoint does store.checkpoint("TRUNCATE"); // → { busy, log, checkpointed }; sidecar back to zero bytes
In WAL mode SQLite lets the -wal sidecar grow to a high-water mark and then
reuses it in place, so a long-lived writer can sit behind a sidecar far larger than
the database itself even though no frames are outstanding. TRUNCATE is the mode
that actually reclaims that space. PASSIVE (the default) copies what it can
without blocking; FULL and RESTART sit between the two.
The result is SQLite's own row: busy is 1 if a reader or writer blocked the
checkpoint, log the frames still in the WAL, checkpointed the frames copied back
into the main database. A database that is not in WAL mode — an in-memory store, or
one opened with journalMode: "DELETE" — answers with -1 counts rather than
failing, so the call is safe to make unconditionally.
close() already checkpoints and removes the -wal/-shm sidecars, so a process
that is exiting cleanly needs nothing extra. Reach for checkpoint("TRUNCATE") when
the handle stays open but the file should shrink — before copying a database file
somewhere, for instance.
Because every non-identity field declares a .default(...), you extend a schema by
appending a defaulted field — no migration, no backfill. Rows written under the old
schema parse cleanly under the new one, with the default filling the gap at read time:
// v1 wrote: { id: "user_legacy", name: "Legacy" } const UsersV2 = z.object({ id: ref("user"), name: z.string().default(""), role: z.enum(["admin", "member"]).default("member"), // new field }); store.collection("users", UsersV2).get("user_legacy"); // → { id: "user_legacy", name: "Legacy", role: "member" }
Identity fields (id, foreign keys) carry no default and fail loudly when absent —
a fabricated id is worse than a missing one. They are the honest exception to the
default rule, and the exemption survives the wrappers that leave a foreign key's
identity intact, so a nullable relation is written as it reads:
z.object({ id: ref("post"), authorId: ref("user").nullable() }); // accepted, no default
.nullable(), .optional(), .describe(), .brand() and .refine() all keep it. A
.default(...) on a reference ends it: a defaulted foreign key invents a reference to a
row that may not exist, so it is held to the ordinary rule — which it passes, because it
declares a default.
Prefer .nullable() over .optional() for a stored reference. Both are accepted, but an
absent .optional() is dropped from the row by JSON.stringify, so the stored key set
varies row to row — the incompleteness the rule below exists to prevent — while
.nullable() stores the explicit null you want anyway.
Reopening a collection may extend the schema and may declare further indexes, which are
cumulative across handles. It may not change idField: identity is what the stored
rows are keyed and shaped by, so a conflicting reopen throws instead of writing two
conventions into one table.
store.collection("ks", z.object({ id: ref("k") })); store.collection("ks", z.object({ slug: ref("k") }), { idField: "slug" }); // throws: collection("ks"): already open with idField "id", cannot reopen with "slug".
The check is case-insensitive, because SQLite identifiers are — "KS" and "ks" are one
table and so one binding.
It survives a close. The binding a handle records lives in memory, so a second
connection — a redeployed process opening a file that already holds rows — starts without
it; the convention is therefore also read back off the rows themselves, because every
write stores the id column as document[idField]. A reopen whose idField is not what a
stored row is keyed by is refused the same way, naming the field the rows carry:
// a fresh process, on a file the snippet above wrote store.collection("ks", z.object({ slug: ref("k") }), { idField: "slug" }); // throws: collection("ks"): stored rows are keyed by idField "id", cannot reopen with "slug".
Nothing of this library's is written to the file to make that work — there is no metadata table — so the guard answers on files that already exist, and on exactly the evidence the rows carry. An empty table carries none, so there the in-process binding is the whole of the check.
That rule is enforced, not documented: store.collection(...) walks an object
schema at creation and refuses a non-identity field with no .default(...),
naming the field. A field with no default is not merely un-forward-compatible — its
undefined is dropped by JSON.stringify, so the key disappears from the stored row
entirely and the key set varies row to row, which is exactly the incompleteness a
stored document must never have. Pass
{ enforceDefaults: false } for a deliberate exception.
The object schema is found through whatever wraps it — .transform(), .pipe(),
.brand(), .default(), z.lazy() — so a wrapper cannot switch the rule off without
saying so. A schema that declares no fields of its own (z.string(),
z.record(z.string(), z.string())) has nothing of its own to enforce and is skipped,
though the walk still descends into what a container stores — see the boundary below. A
schema whose fields are not one readable shape — a union of object schemas, an
intersection — is refused, because enforcing nothing there would be a rule reporting a
check it never ran:
store.collection("variants", z.union([DraftSchema, FinalSchema])); // throws: the schema's fields cannot be read as one shape … store.collection("variants", z.union([DraftSchema, FinalSchema]), { enforceDefaults: false }); // accepted — the schema's fields are now yours to hold to the rule
The guard's reach is the guarantee's reach, so its boundary is stated here rather than left to be rediscovered. The walk is recursive: a default on an enclosing object does not cover its members, because a row that already stores the object is parsed against every one of them. The error names the full path.
// v1 wrote: { id: "s_old", settings: { theme: "light" } } store.collection("s", z.object({ id: ref("s"), settings: z.object({ theme: z.string().default("light"), fontSize: z.number() }) .default({ theme: "light", fontSize: 14 }), })); // throws: field "settings.fontSize" has no default … // — refused here, rather than accepted and then failing every read of an old row.
| Where the walk goes | What happens |
|---|---|
| A declared field, at any depth | Held to the rule, then descended into — settings.fontSize |
What a container stores — an array's elements, a tuple's declared positions and its rest tail, a record's values, an object's .catchall() keys |
Descended into: each is a schema an already-stored value is parsed against, whether or not a declared field name reaches it — tags[].color, pair[0].x, pair[].x (the tail), prefs.<key>.size, bag.<key>.size (the catchall) |
A ref() foreign key |
Exempt at any depth — identity-shaped wherever it sits |
A member named like idField |
Exempt only at the top level: that name is the column the rows are keyed by, so a nested id is an ordinary field and needs a default — declare a recursive document's identity with ref(), which is exempt wherever the cycle reaches it |
| A nested union or intersection | Refused, naming the field, on the same terms as a top-level one |
| A shape the walk has already seen | Skipped — this is what lets a self-referential schema terminate; its members were held to the rule |
| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |