Net4x.DapperLibrary.SQLite 1.9.9.8

DapperLibrary.SQLite

SQLite provider integration for DapperLibrary. This project provides a SQLite-specific DapperContext implementation, a provider factory and database model/type mappings tailored for SQLite.

Purpose

Make DapperLibrary work naturally with SQLite by providing:

• SQLiteDapperContext � a DapperContext configured for the SQLite ADO.NET provider with convenient Use / UseOnce helpers.
• SQLiteProviderFactory � configures parameter behavior, data adapter hooks and the DatabaseModel factory for SQLite.
• SQLiteDatabaseModel / SQLiteDatabaseModelTypes / SQLiteDatabaseEnumTypes � SQLite-specific delimiters, batch terminator, parameter naming and SQL type mappings.
• SQLiteClientFactory � a small DbProviderFactory wrapper producing SQLite ADO.NET objects used by the provider factory.

Key types

• SQLiteDapperContext

  • Derives from DapperContext and wires a SQLiteProviderFactory instance.
  • Provides static Use, Use(IContextCreator), Use(string, string) and UseOnce helpers to integrate with DapperContextFactory and to configure context creation for tests and applications.
  • Default in-memory connection string is provided: Data Source=InMemory;Mode=Memory;Cache=Shared (registered as a DapperConnectionStringSettings alias named ConnectionString).

• SQLiteProviderFactory

  • Inherits from ProviderFactoryBase and uses SQLiteClientFactory.Instance.
  • Sets ParameterModel.AddIndex = true and AddPrefixInParameterName = false to match SQLite parameter behavior.
  • Installs a PrepareCommandParameters delegate and wires RowUpdated / RowUpdating events on created DbDataAdapter instances.

• SQLiteDatabaseModel and related types

  • Delimiters: " (double-quote) for identifiers.
  • Batch terminator: ;.
  • Parameter prefix: $ and parameter base name: Par.
  • Type mappings reflect SQLite capabilities (e.g. Int32/Int64 as INTEGER, Text as TEXT, Blob as BLOB, Decimal/Double as REAL).

• SQLiteClientFactory

  • A custom DbProviderFactory wrapper that constructs SQLiteCommand, SQLiteConnection, SQLiteDataAdapter, etc., and is used so the provider factory can remain provider-agnostic.

Usage examples

Create and use a SQLiteDapperContext directly:

using var context = new SQLiteDapperContext();
// use context.Operations / context.Schema / context.SaveDataTable etc.

Register a creator for test or application bootstrap:

// simple registration for shared usage
SQLiteDapperContext.Use();

// or bind an explicit connection string and provider
SQLiteDapperContext.UseOnce("Data Source=mydb.sqlite;","System.Data.SQLite");

In-memory testing:

// default alias in the library points to Data Source=InMemory;Mode=Memory;Cache=Shared
using var context = new SQLiteDapperContext();
// create tables and execute test queries against the in-memory DB

When using DbDataAdapter-based save operations, you can subscribe to row update events via the provider factory which raises RowUpdating/RowUpdated events.

Multi-targeting & client compatibility

• The project is multi-targeted with conditional compilation present in the solution to support older .NET Framework targets and modern .NET runtimes used throughout the repository.
• This project depends on System.Data.SQLite (the native ADO.NET SQLite provider). Ensure the consuming project references the correct SQLite ADO.NET package for its target framework.

Synchronous vs asynchronous usage

• The DapperLibrary core exposes both synchronous and asynchronous APIs; the SQLite-specific provider and the System.Data.SQLite ADO.NET provider historically have limited or provider-specific async support. As a result:
  • Prefer synchronous methods when targeting runtimes/providers that do not implement true async I/O.
  • Use the async variants (GetDataReaderAsync, GetDataTableAsync, SetDataAsync, etc.) in environments where the underlying provider supports async methods and you need non-blocking behavior.
  • When writing tests against the in-memory SQLite connection, synchronous operations are often simpler and reliable due to provider semantics.

Notes and best practices

• SQLite parameter naming in this library uses $ as the prefix and does not automatically add a prefix to parameter names (AddPrefixInParameterName = false), so pass parameter names consistently with that convention when building raw commands.
• The default in-memory connection string is useful for unit tests. For durable storage, provide a file-based connection string.
• The provider factory ensures parameter indexing (via ParameterModel.AddIndex = true) which keeps the parameter placeholder handling consistent with other providers in the DapperLibraries solution.

Consult source files under DbContexts and SQLite for implementation details and for extension points.