Joseph Doherty
12e6f0d2c5
SQLite creates the database FILE on demand but never its parent DIRECTORY, and
SqliteLocalDb opens the file eagerly in its constructor — so a configured path
under a not-yet-existing directory was a hard startup failure ("SQLite Error
14: unable to open database file") rather than a first run that just worked.
Relative defaults like ./data/app.db hit it routinely; a containerized consumer
escapes only when a volume mount happens to create the directory first.
ScadaBridge found this during LocalDb Phase 2 and worked around it app-side
(SiteLocalDbDirectory.Ensure). Every other consumer still had the gap, so the
guarantee belongs here.
The standing objection to a library that creates directories is that it can
mask a mis-typed path by silently starting an empty database. That does not
apply: SQLite ALREADY does exactly that for a mis-typed file NAME. Refusing to
create the directory protects nothing — it only makes the two halves of one
path behave inconsistently and turns the directory half into an opaque error.
A creation failure (permissions, read-only mount) now throws an
InvalidOperationException naming the directory and the cause, instead of
surfacing as SQLite error 14. That is a change of exception type, but only on a
path that already failed hard.
Both behaviours are pinned and verified to fail with the call removed.
147 tests pass, 0 warnings. Published to the Gitea feed at 0.1.1.
Claude-Session: https://claude.ai/code/session_01BL2Vu1ESDQ9SCN4gVKkdts
25 lines
1.1 KiB
XML
25 lines
1.1 KiB
XML
<Project>
|
|
|
|
<PropertyGroup>
|
|
<TargetFramework>net10.0</TargetFramework>
|
|
<Nullable>enable</Nullable>
|
|
<ImplicitUsings>enable</ImplicitUsings>
|
|
<LangVersion>latest</LangVersion>
|
|
<Version>0.1.1</Version>
|
|
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
|
|
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
|
|
<!-- NU1510 (package-pruning advice): the Replication and Tests projects carry a
|
|
Microsoft.AspNetCore.App FrameworkReference AND explicit PackageReferences to
|
|
in-framework packages (Hosting/Logging/DI/Configuration), as required by the
|
|
library layout. The advice is benign; keep the explicit refs and silence it. -->
|
|
<NoWarn>$(NoWarn);NU1510</NoWarn>
|
|
<PackageReadmeFile>README.md</PackageReadmeFile>
|
|
</PropertyGroup>
|
|
|
|
<!-- Embed the repo README in each packable nupkg (ignored by non-packable projects). -->
|
|
<ItemGroup Condition="'$(IsPackable)' == 'true'">
|
|
<None Include="$(MSBuildThisFileDirectory)README.md" Pack="true" PackagePath="\" Visible="false" />
|
|
</ItemGroup>
|
|
|
|
</Project>
|