<init>

NativeSqliteDriver(configuration: <ERROR CLASS>)

Platform and version requirements: native

NativeSqliteDriver(schema: <ERROR CLASS>, name:String)

Platform and version requirements: native

NativeSqliteDriver(databaseManager: <ERROR CLASS>)

Platform and version requirements: native

Native driver implementation.

The root SqlDriver creates 2 connections to the underlying database. One is used by transactions and aligned with the thread performing the transaction. Multiple threads starting transactions block and wait. The other connection does everything outside of a connection. The goal is to be able to read while also writing. Future versions may create multiple query connections.

When a transaction is started, that thread is aligned with the transaction connection. Attempting to start a transaction on another thread will block until the first finishes. Not ending transactions is problematic, but it would be regardless.

One implication to be aware of. You cannot operate on a single transaction from multiple threads. However, it would be difficult to find a use case where this would be desirable or safe.

To use SqlDelight during create/upgrade processes, you can alternatively wrap a real connection with wrapConnection.

SqlPreparedStatement instances also do not point to real resources until either execute or executeQuery is called. The SqlPreparedStatement structure also maintains a thread-aligned instance which accumulates bind calls. Those are replayed on a real SQLite statement instance when execute or executeQuery is called. This avoids race conditions with bind calls.