class StatementSync

This class represents a single prepared statement. This class cannot be instantiated via its constructor. Instead, instances are created via thedatabase.prepare() method. All APIs exposed by this class execute synchronously.

A prepared statement is an efficient binary representation of the SQL used to create it. Prepared statements are parameterizable, and can be invoked multiple times with different bound values. Parameters also offer protection against SQL injection attacks. For these reasons, prepared statements are preferred over hand-crafted SQL strings when handling user input.

Constructors #

#StatementSync()

new

Properties #

#expandedSQL: string

readonly

The source SQL text of the prepared statement with parameter placeholders replaced by the values that were used during the most recent execution of this prepared statement. This property is a wrapper around sqlite3_expanded_sql().

#sourceSQL: string

readonly

The source SQL text of the prepared statement. This property is a wrapper around sqlite3_sql().

Methods #

#all(...anonymousParameters: SQLInputValue[]): Record<string, SQLOutputValue>[]

This method executes a prepared statement and returns all results as an array of objects. If the prepared statement does not return any results, this method returns an empty array. The prepared statement parameters are bound using the values in namedParameters and anonymousParameters.

#all(namedParameters: Record<string, SQLInputValue>,
...anonymousParameters: SQLInputValue[],
): Record<string, SQLOutputValue>[]

#get(...anonymousParameters: SQLInputValue[]): Record<string, SQLOutputValue> | undefined

This method executes a prepared statement and returns the first result as an object. If the prepared statement does not return any results, this method returns undefined. The prepared statement parameters are bound using the values in namedParameters and anonymousParameters.

#get(namedParameters: Record<string, SQLInputValue>,
...anonymousParameters: SQLInputValue[],
): Record<string, SQLOutputValue> | undefined

#iterate(...anonymousParameters: SQLInputValue[]): Iterator<Record<string, SQLOutputValue>>

This method executes a prepared statement and returns an iterator of objects. If the prepared statement does not return any results, this method returns an empty iterator. The prepared statement parameters are bound using the values in namedParameters and anonymousParameters.

#iterate(namedParameters: Record<string, SQLInputValue>,
...anonymousParameters: SQLInputValue[],
): Iterator<Record<string, SQLOutputValue>>

#run(...anonymousParameters: SQLInputValue[]): StatementResultingChanges

This method executes a prepared statement and returns an object summarizing the resulting changes. The prepared statement parameters are bound using the values in namedParameters and anonymousParameters.

#run(namedParameters: Record<string, SQLInputValue>,
...anonymousParameters: SQLInputValue[],
): StatementResultingChanges

#setAllowBareNamedParameters(enabled: boolean): void

The names of SQLite parameters begin with a prefix character. By default,node:sqlite requires that this prefix character is present when binding parameters. However, with the exception of dollar sign character, these prefix characters also require extra quoting when used in object keys.

To improve ergonomics, this method can be used to also allow bare named parameters, which do not require the prefix character in JavaScript code. There are several caveats to be aware of when enabling bare named parameters:

The prefix character is still required in SQL.
The prefix character is still allowed in JavaScript. In fact, prefixed names will have slightly better binding performance.
Using ambiguous named parameters, such as $k and @k, in the same prepared statement will result in an exception as it cannot be determined how to bind a bare name.

#setReadBigInts(enabled: boolean): void

When reading from the database, SQLite INTEGERs are mapped to JavaScript numbers by default. However, SQLite INTEGERs can store values larger than JavaScript numbers are capable of representing. In such cases, this method can be used to read INTEGER data using JavaScript BigInts. This method has no impact on database write operations where numbers and BigInts are both supported at all times.