Part of the program master #5119, epic #5110. Listed there as "future, not yet issued" — this issues it.
The compliance library has two consumers, both mature, both built by the same people, both on the same JasperFx version. That is exactly the configuration in which a "portable" seam quietly accumulates residue: an assumption that holds on PostgreSQL and SQL Server, encoded in a suite, and nobody notices.
A third consumer is the only real test. The planned minimal store — JasperFx.Events + Weasel.Storage + Weasel.Sqlite — is the intended one, and its value here is diagnostic before it is functional: every place the compliance suites fail against a from-scratch implementation is either a genuine store gap or a leak in the seam, and both are findings worth having.
Scope
- Stand up the minimal Sqlite-backed event store far enough to build a schema, append events, and read them back
- Implement
EventStoreComplianceFixture<TOperations, TQuerySession> against it
- Enroll the suites and record, per suite: passes / fails-as-product-gap / fails-as-seam-leak
- Fix the seam leaks upstream; file the product gaps against the Sqlite store; use capability gates only for behavior the minimal store deliberately will not have (e.g. the async daemon, if it does not ship one initially —
SupportsAsyncDaemon already exists for exactly this)
Why it is worth doing before the library grows further
Every wave adds suites written against two engines. The later the third consumer arrives, the more residue there is to unwind. This does not have to block wave growth, but it should not wait for the wave list to empty either.
Acceptance
- A third fixture implementation exists and runs the suites
- Each failure is classified (product gap vs seam leak) rather than gated by default
- Any seam leak found is fixed in
JasperFx.Events.ComplianceTests, not worked around in the Sqlite fixture
Part of the program master #5119, epic #5110. Listed there as "future, not yet issued" — this issues it.
The compliance library has two consumers, both mature, both built by the same people, both on the same JasperFx version. That is exactly the configuration in which a "portable" seam quietly accumulates residue: an assumption that holds on PostgreSQL and SQL Server, encoded in a suite, and nobody notices.
A third consumer is the only real test. The planned minimal store — JasperFx.Events + Weasel.Storage + Weasel.Sqlite — is the intended one, and its value here is diagnostic before it is functional: every place the compliance suites fail against a from-scratch implementation is either a genuine store gap or a leak in the seam, and both are findings worth having.
Scope
EventStoreComplianceFixture<TOperations, TQuerySession>against itSupportsAsyncDaemonalready exists for exactly this)Why it is worth doing before the library grows further
Every wave adds suites written against two engines. The later the third consumer arrives, the more residue there is to unwind. This does not have to block wave growth, but it should not wait for the wave list to empty either.
Acceptance
JasperFx.Events.ComplianceTests, not worked around in the Sqlite fixture