[jasperfx] Shared batch-DCB query interface + Marten/Polecat implementations (P3.2b)

[jeremydmiller]

Part of #5110. Target repo: JasperFx/jasperfx for the interface, then small follow-up PRs in Marten and Polecat to implement it (tracked here).

The batched-query DCB surface is the one seed-suite seam with no JasperFx abstraction at all, and the two products expose the same operations at different paths:

• Marten: batch.Events.EventsExist(query) / batch.Events.FetchForWritingByTags<T>(query) via IBatchEvents Events { get; } on IBatchedQuery (src/Marten/Services/BatchQuerying/IBatchedQuery.cs)
• Polecat: batch.EventsExist(query) / batch.FetchForWritingByTags<T>(query) flat on its IBatchedQuery (src/Polecat/Batching/IBatchedQuery.cs)

Method names/signatures already match exactly — only the accessor path differs.

Proposal: add to JasperFx.Events something like

public interface IBatchedEventQueries
{
    Task<bool> EventsExist(EventTagQuery query);
    Task<IEventBoundary<T>> FetchForWritingByTags<T>(EventTagQuery query) where T : class;
}

with Marten's IBatchEvents and Polecat's IBatchedQuery (or its batch-events sub-object, added for source compatibility) implementing it. The compliance seam's IComplianceBatch then becomes a thin adapter — or disappears once both stores expose the shared interface from CreateBatchQuery().

Exact shape should be finalized against the DCB suite's real usage in P3.1b before the jasperfx PR goes up (the suite work will prove whether Execute(ct) belongs on the shared interface or stays store-side). Polecat-side implementation is a hand-off item.

🤖 Generated with Claude Code

[jeremydmiller]

Finalized the shape against real usage in #5112, as this issue asked for. Recommend deferring — the interface would not remove IComplianceBatch, which was the payoff.

The open question here was whether Execute(ct) belongs on the shared interface. The suites answer it: it does not. Execute is a property of the batch, not of the event queries hanging off it, and it is what the compliance code actually has to call:

var batch = CreateBatch(session2);
var boundaryTask = batch.FetchForWritingByTags<StudentCourseEnrollment>(query);
await batch.Execute(Cancellation);      // <- returned tasks do not complete until this runs
var boundary = await boundaryTask;

So a shared IBatchedEventQueries carrying only EventsExist / FetchForWritingByTags still leaves the seam needing a per-store adapter to reach Execute, plus the accessor difference is one line per store:

• Marten: _batch.Events.EventsExist(query)
• Polecat: _batch.EventsExist(query)

Against that, landing it costs a JasperFx.Events release plus coordinated bumps in both products. Net benefit today is close to zero.

Worth revisiting if a third store shows up, or if the interface grows to include Execute and both products can return it directly from CreateBatchQuery(). Until then the divergence is fully absorbed by IComplianceBatch — the concrete adapters are 10 lines each and are documented as temporary.

[jeremydmiller]

Closing as not planned, per the investigation above and the Phase 3 wrap-up on #5110.

This issue asked P3.1b to settle whether Execute(ct) belongs on the shared interface. Real usage settled it: it does not — Execute is a property of the batch, not of the event queries hanging off it, and it is what the compliance code actually has to call. So a shared IBatchedEventQueries carrying only EventsExist / FetchForWritingByTags still leaves the seam needing a per-store adapter to reach Execute, and IComplianceBatch — the thing this was meant to retire — survives either way.

Against a net-zero benefit, landing it costs a JasperFx.Events release plus coordinated bumps in both products. The accessor difference it would remove is one line per store.

Both adapters shipped and are ~10 lines each (MartenComplianceFixture.MartenComplianceBatch, PolecatComplianceFixture.PolecatComplianceBatch).

Worth revisiting if a third store appears (the planned Sqlite one), or if the interface can grow to include Execute and both products return it directly from CreateBatchQuery().