SQLite (sqlite)
SQLite data driver deployment, connection configuration and ad hoc validation.
Access the in-process database through Microsoft.Data.Sqlite. Application deployment needs to retain the native runtime library, and the file library also needs correct directory and file permissions. The application uses it through Data Access Interfaces or Data Services, and the public mapping, conditions and data schema still follow the organization of the data engine.
source code directory
Zongsoft.Data/drivers/sqlite
NuGet package
Zongsoft.Data.SQLite
Connection and Script Driver Key
SQLite
Deployment and Connection
Append the following snippet to the existing host's deployment manifest. If Data has been deployed, there is no need to declare the same package again; the driver's manifest, assembly and runtime dependencies should be delivered together, see Deployment Tool.
[plugins zongsoft data]
nuget:Zongsoft.Data
[plugins zongsoft data sqlite]
nuget:Zongsoft.Data.SQLiteTraceable Integration Example
Discussions There is currently no database script for this driver. The integration example uses the test project of the framework driver. Test models, mapping and initialization scripts should be used as a set, and Discussions table building scripts in other dialects cannot be directly considered compatible.
Source: framework/Zongsoft.Data/drivers/sqlite/test/DatabaseFixture.cs (excerpt; see source for context).
private static readonly string DATABASE_FILE = Path.Combine(AppContext.BaseDirectory, "test.db");
private static readonly string CONNECTION_STRING = $"DataSource={DATABASE_FILE};PRAGMA:optimize;PRAGMA:journal_mode=WAL;PRAGMA:synchronous=NORMAL;PRAGMA:temp_store=MEMORY;";Source: framework/Zongsoft.Data/drivers/sqlite/test/DatabaseFixture.cs (excerpt; see source for context).
Here Test is the test accessor name, CONNECTION_STRING and DATABASE_FILE are from the same fixture. This fixture deletes the test files and executes the init script, which can only be run in the test output directory. SQLite's WAL parameters and DuckDB's file paths are both part of existing tests, which does not mean that Discussions has been adapted to both databases.
The plugin host's connection items are still placed in /Data/ConnectionSettings, and the driver keys use the canonical names in the index of this page. The accessor name obtained by the business must correspond to the deployment configuration; Discussions obtains the accessor by module name, and the test fixture explicitly passes in the connection settings in the code. The difference between the two entrances is shown in Connections and data sources. The named SQL is still determined by its script's driver, and switching connections will not translate handwritten SQL.
What Should You Pay Attention to with This Driver?
How to Verify After Integration
You can first complete the first query without a table, and then prepare the business table in an independent file library. Then verify the results of foreign keys, concurrent writes, lock waits, and reopening after closing. When checking backup and replacement files, you must consider log files and connections that are still occupied by the database.
Validation should cover a query, a set of actual written data, failure recovery, and then scale to production workloads. Common constraints can be checked against Driver selection and acceptance, Connection Configuration, and Transactions and Consistency.
Project Resources
source code directory · Plugin Manifest · Chinese project description
Last updated