DataLinq 0.9 Release Notes
Note
This is the release-note draft for the 0.9 release candidate. It does not claim that packages have been published.
DataLinq 0.9 makes provider values explicit, makes read execution backend-selectable, expands typed-ID and UUID correctness, and introduces an experimental read-only in-memory backend.
Highlights
Backend-selectable query execution
The production LINQ path now creates a self-contained query template and invocation, selects a source-owned backend, and validates the complete plan against an explicit capability profile before backend work. Existing SQL execution remains the authoritative path for MySQL, MariaDB, and SQLite.
Unsupported shapes fail with DataLinq-owned diagnostics instead of silently switching to unrestricted client-side LINQ.
Scalar converters, typed IDs, and UUID storage
0.9 separates three representations that used to blur together:
- the public model value, such as
EmployeeId - the canonical provider value, such as
Guid - the provider's physical text, native UUID, or binary layout
That boundary is used across the supported read, write, key, cache, relation, query-value, and schema-validation paths. SQLite, MySQL, and MariaDB can therefore use explicit per-column UUID storage without leaking byte order or text encoding into model values or cache identity.
Experimental DataLinq.Memory
The new DataLinq.Memory package provides a provider-free, read-only store for generated models:
- explicit generated-mutable seeding
- exact single-column primary-key lookup, including typed IDs
- a small capability-gated query subset
- direct scalar projection to strings, nullable values,
Guid, and converter-backed typed IDs - predictable rejection of unsupported queries before partial execution
- Native AOT, trimming, and browser/WebAssembly support for the documented generated-model path
See DataLinq.Memory for the supported boundary and examples.
SQL transaction and mutable-lifecycle correctness
The managed transaction path now treats failed mutations and uncertain completion conservatively. Transaction-derived mutable instances are invalidated when their baseline cannot be trusted, committed publication and local finalization have an explicit order, and rollback, known-committed finalization failure, unknown commit outcome, external completion, and disposal remain distinct states.
Low-level provider handles can bypass those managed guarantees. Do not reuse an underlying connection or transaction after an uncertain provider failure.
Packaging and platforms
The 0.9 package set is:
DataLinqDataLinq.SQLiteDataLinq.MySqlDataLinq.MemoryDataLinq.CLIDataLinq.Tools
Packages target .NET 8, .NET 9, and .NET 10. Keep all DataLinq package versions aligned.
Upgrade notes
- Rebuild generated models after upgrading; generator and generated binding details changed in 0.9.
- Review configured
Guidand typed-ID columns and make their physical storage explicit when an existing schema is ambiguous. - Keep using provider-backed integration tests for SQL translation, collation, constraints, defaults, transactions, and migrations. Memory is not a drop-in database emulator.
- Existing unsupported LINQ shapes may now fail earlier with a capability diagnostic. That is intentional and avoids partial backend work.
The current development API comparison against 0.8 has no known hard compatibility break. The final release-candidate comparison remains part of the publication checklist.
Known limitations
- DataLinq still supports a documented LINQ subset, not arbitrary LINQ.
DataLinq.Memoryis experimental, read-only, and intentionally lacks relations, mutation, transactions, and persistence.- Browser SQLite support remains limited to the documented generated WebAssembly smoke path and retains visible third-party SQLitePCLRaw warnings.
- Migration execution, native async database I/O, DI/hosting integration, and broad multi-join/composite-key work remain future work.
CHANGELOG.mdis generated from published GitHub releases and will be updated only after publication.