Rask.SQLite.EntityFrameworkCore 0.20.1-alpha.0.207

Rask.SQLite.EntityFrameworkCore

The Entity Framework Core integration for Rask.SQLite. UseRaskSqlite(...) is a drop-in replacement for UseSqlite that also wires a ConnectionOpened interceptor applying the production pragma set — WAL, synchronous=NORMAL, foreign_keys=ON, a busy_timeout, mmap_size, journal_size_limit — to every connection the context opens.

It also makes decimal correct. EF Core stores one as invariant TEXT and sorts it with a collating sequence it registers as decimal.Parse(x) — with no IFormatProvider, so it reads that invariant text under the machine's CurrentCulture. On de-DE an ORDER BY silently mis-sorts ("19.95" parses as 1995); on en-HU it throws inside a native callback that cannot be unwound and takes the process down. UseRaskSqlite re-registers the collation invariantly on every open, changing nothing in the database file — no column type, no DDL, no migration.

Split out from Rask.SQLite so apps that only use the raw Microsoft.Data.Sqlite path (or run on mobile / under AOT, where you don't want EF Core) can stay lean.

Install

dotnet add package Rask.SQLite.EntityFrameworkCore

Use

builder.Services.AddDbContextFactory<AppDb>(o =>
    o.UseRaskSqlite($"Data Source={dbPath}"));

Override any pragma via the optional configure delegate:

o.UseRaskSqlite($"Data Source={dbPath}", p =>
{
    p.BusyTimeout = TimeSpan.FromSeconds(10);
    p.CacheSize = -20_000;   // negative ⇒ KiB, so 20 MB
});

STRICT tables

SQLite is dynamically typed: the text "lots" stores happily in an INTEGER column and surfaces as a cast error much later. Pass o => o.StrictTables = true and tables are created as STRICT tables, so the store rejects the write instead:

o.UseRaskSqlite($"Data Source={dbPath}", o => o.StrictTables = true);

Every column must then declare one of INT, INTEGER, REAL, TEXT, BLOB or ANY — EF Core's defaults all qualify, so a normal model needs no changes, and an explicit HasColumnType(...) outside that set is reported against the table and column it came from. Strictness is decided when a table is created, so this needs no migration and affects tables created from then on; rask new --data scaffolds it on, where it is free.

Busy-retry for SaveChanges

Pass configureRetry (even empty) to register a fair-interval execution strategy so SaveChanges/queries retry on SQLITE_BUSY/SQLITE_LOCKED at a constant 1 ms interval, awaiting (not blocking) between attempts:

o.UseRaskSqlite($"Data Source={dbPath}", o => o.Retry.Enabled = true);

The truly non-blocking, BEGIN IMMEDIATE write path lives in Rask.SQLite (InImmediateTransactionAsync); see the docs for when to reach for it.

Non-overlapping ranges

UseRaskSqlite also enforces Rask.Data's HasNonOverlappingRange(...): migrations emit an index plus a BEFORE INSERT/BEFORE UPDATE trigger pair, re-emitted after the table rebuilds SQLite needs for most ALTERs (which would otherwise drop them). A violating save throws RangeOverlapException naming the table. Both are inert until an entity declares a rule.

Not using EF Core? Use Rask.SQLite directly: services.AddRaskSqlite(cs) + inject ISqlite.

Full documentation: https://github.com/pal-tamas/rask/blob/main/docs/sqlite.md