Skip to content

Implement IDocumentStoreDiagnostics for EF Core DbContexts, so tools can browse and filter entity rows #5297

Closed

Description

@jeremydmiller

Goal

Implement JasperFx's IDocumentStoreDiagnostics for an EF Core DbContext in Wolverine.EntityFrameworkCore, so a monitoring tool can list a context's entity types and browse, filter and sort their rows through the same abstraction it already uses for Marten, Polecat and Fisher documents.

Why

CritterWatch's document explorer reaches every store only through IDocumentStoreDiagnostics. An implementation for a DbContext would give EF Core users filtering in C# property names, column selection, exports and query plans, with almost nothing new on the monitoring side.

Proposal

One implementation per registered DbContext, alongside the existing DbContextUsageSource<T>, opening a fresh scope per read:

Member Implementation
Subject The efcore://{ContextName} URI DbContextUsageSource<T> already reports
DocumentTypesAsync The model's entity types
QueryDocumentsAsync Set<T>().AsNoTracking() plus DocumentQueryOptions.ApplyCriteriaTo<T>, which works on any IQueryable<T>, with IsTranslationFailure for a clause EF Core cannot translate
LoadDocumentAsync By primary key
ExplainDocumentQueryAsync ToQueryString, then the provider's own plan where it has one

The write members stay at their defaults. This is reads only: SaveChanges can run application interceptors and domain events, which is a separate decision.

Things to get right

  • Serialize scalar properties only. Navigation properties can cycle and can trigger lazy loading. Never Include.
  • Owned, keyless and view types. Owned types are not queryable alone, and keyless types have no id for a load. Report what can be queried rather than failing a read.
  • Wolverine's own mapped entities. IncomingMessage and OutgoingMessage are mapped into a context with the outbox. They should be identifiable, so a tool can leave them out.
  • Tenancy. Conjoined, database-per-tenant and PartitionPerTenant each differ. Honour DocumentQueryOptions.TenantId and AllTenants through the same tenant-aware path Wolverine already uses to open a context, and do not bypass a query filter by accident.
  • Refuse rather than answer wrongly. A criterion that cannot be applied throws, as the interface requires. It never returns an unfiltered page.
  • DocumentQueryCriteria.IsAvailable is false where dynamic code is not supported.

Related

#5296 asks for the same query path for EF Core sagas, since a saga there is an entity in a DbContext. Doing them together should mean one implementation.

Activity

  1. added a commit that references this issue on Oct 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions