Skip to content

CSharpDB v4.4.0

Choose a tag to compare

@github-actions github-actions released this 05 Aug 18:10
· 22 commits to main since this release
86e2543

Current Release

The current release completes the bounded SQL implementation and makes its release claims reproducible. The public reference, provider behavior, migration capability contracts, recovery tests, and release workflow now describe the same supported surface; publishing remains gated on the recorded qualification passes described below.

SQL and Schema Coverage

  • Completed the bounded window-function slice with explicit ROWS frames, named windows, compatible shared ordering, navigation/value functions, cancellation, prepared execution, and explicit in-memory resource limits.
  • Added the full immediate foreign-key action matrix for deletes and referenced-key updates, including composite relationships and transactional nested cascades.
  • Added transactional shadow-root ALTER COLUMN rewrites for the supported numeric, UTF-8 text/BLOB, and collation shapes, including atomic rebuilding of eligible indexes, plus validated transactional catalog updates for literal-default and nullability changes.
  • Added logical composite INTEGER/TEXT keys and bounded populated single-INTEGER primary-key rekeying with relational and complete ready full-text-owned storage rebuilding.
  • Added stable physical EXPLAIN and EXPLAIN ANALYZE rowsets with estimated and actual values, operator/access-path metadata, redacted predicates, partial safe diagnostics, and direct/ADO.NET/HTTP/gRPC access.
  • Unsupported SQL forms now fail with stable diagnostics instead of being silently accepted; documentation tests execute every concrete public SQL example from its published source, parser-check the parameterized example, and classify schematic grammar templates separately.

Provider and Compatibility Qualification

  • Added a replayable EF Core generated-SQL corpus covering defaults, checks, composite and named relationships, referential actions, key changes, column rewrites, table/column/index rename chains, stable diagnostics for unsupported database sequence operations, rollback, reopen, upgrade/downgrade, runtime CRUD, and ADO.NET schema inspection.
  • Added immutable database fixtures produced by supported historical releases, with recorded commits and checksums, then qualified current write, checkpoint, recovery, and reopen behavior against each fixture.
  • Added one canonical typed workload across the direct engine, embedded ADO.NET, HTTP, and gRPC paths. This qualification found and fixed HTTP BLOB results being returned as base64 text rather than bytes.
  • Added deterministic bounded property coverage for parser expressions, constraint graphs, and type conversions, plus fault-injected WAL commit recovery for schema rewrites and multi-level cascades.

Release Gate

  • Added a reusable release qualification workflow that runs the full solution and provider/tooling checks twice from clean environments on Windows, Linux, and macOS before publishing can begin. It supports manual dispatch after registration on the default branch and non-release qualification-* tags for qualifying an exact pre-merge candidate commit.
  • Added a sequential local durable-write release gate for an idle fixed-SSD Windows machine after repeated GitHub-hosted runs demonstrated non-qualifying transient disk variance. Two balanced paired passes qualify each of the ten file-backed, hybrid durable, and direct-client SQL/collection single and batch write rows independently with adjacent previous/candidate measurements, a reversed starting order in pass two, and per-measurement floors of 30 seconds and 10,000 retained latency samples. Each logical side has one predeclared attempt; evidence is never discarded, replaced, or silently retried. The expected runtime is 3.5–4.5 hours. The canonical durable-v3 policy pins both engine commits, uses symmetrically conditioned artifacts with the same hash-recorded candidate benchmark harness, and retains hash-verified raw evidence outside the repository. After post-build quiescence, a required one-second Windows monitor records observable external process CPU and I/O while retaining system CPU outside the observable runner tree as diagnostic evidence through the final measurement. Five consecutive samples above either 8% observable external process CPU, 0.5 CPU-core equivalent, or 4,194,304 observable process I/O bytes per second contaminate the pass; named build, test, installer, and update processes contaminate immediately. Missing monitor evidence, unavailable allowed runner-tree CPU, a coverage gap above five seconds, benchmark-evidence failures, or invalid installer, event-log, or pending-file evidence fails closed; unavailable external-process counters remain explicit diagnostics. The gate blocks at 15% throughput regression and blocks P95 only when regression exceeds both 25% and 0.05 ms; P99 remains diagnostic. A successful exact-commit status has the policy-bound description policy=durable-v3; baseline=<40 lowercase hex>; design=<8 uppercase hex>; reports=<8 uppercase>/<8 uppercase> and must be created by the configured attestor; older policy descriptions are rejected. GitHub continues to run two clean functional qualification passes on Windows, Linux, and macOS plus paired comparisons for the other 18 stable master-table rows using the same blocking throughput/P95 policy and diagnostic P99; broader performance suites remain manual or report-only diagnostics.
  • Hardened benchmark phase shutdown so normal coordinated worker cancellation has bounded scheduling grace on busy runners, while already-failed cleanup remains prompt and genuinely unresponsive work still produces an explicit diagnostic.
  • Added diagnostic-only exact hybrid-row controls with five pairs per order, an optional directly executed same-revision DLL whose hash is verified around every sample, separate revision build-input identities, build-server shutdown plus a fixed wait, and a fail-closed 30-second plus 10,000-retained-sample floor with a 120-second measurement cap. These controls diagnose benchmark stability and do not satisfy the two-revision release gate.
  • Preserved the immutable prior-release migration capability catalog and added a separately digested current-release catalog so older migration plans remain independently replayable.