You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Implement IDocumentStoreDiagnostics for EF Core DbContexts, so tools can browse and filter entity rows #5297
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
GH-5297 IDocumentStoreDiagnostics for EF Core DbContexts (#5302)