Support configuring a model-level filter on a navigation

Aperta
  • Qualcosa non va?
#39,421 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
database

Direzione di ricerca

Start with NavigationExpandingExpressionVisitor.cs and review the related query-filter and filtered-Include handling described in the issue. The issue leaves the API and core behavior across query translation, loading, tracking, mutation, and filter bypass open for design. Done means a defined, validated model-level predicate for an individual navigation with consistent supported query and loading behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area-query

An application may need a navigation to expose a filtered subset of related entities consistently, without applying the same predicate at every query or loading call site.

For example, a blog could expose both all of its posts and a separate PublishedPosts navigation containing only published posts. Queries over PublishedPosts, including Any, Count and projection, should use that predicate automatically. Loading the navigation should use the same definition.

The filter belongs to a particular navigation, not to the target entity type globally: unpublished posts should remain queryable directly and through other navigations.

Existing support and workarounds
  • Filtered Include applies a filter at a particular query call site. It does not define the navigation's meaning throughout the model or apply that predicate to ordinary navigation access elsewhere in a query.
  • Global query filters apply to an entity type, not independently to one navigation targeting it.
  • Explicit Where expressions and projections can select the desired subset, but require callers to repeat the condition and do not establish reusable navigation loading semantics.
  • A computed CLR property over an already-loaded collection does not provide a mapped, server-translatable navigation.

Existing query-filter and filtered-Include handling in NavigationExpandingExpressionVisitor provides related infrastructure, but is not itself model-level navigation filter configuration.

Describe the solution you'd like

Allow a predicate to be configured for an individual navigation in model metadata. Query translation and supported loading mechanisms should apply that predicate whenever the navigation is used.

The initial scenario is a collection navigation filtered on target properties, such as published posts. The design should define whether predicates can also refer to source-entity properties or context-dependent values, and how reference navigations are handled. The exact fluent API needs design.

Design considerations
  • Navigation-specific scope: Apply the filter only when traversing the configured navigation. Do not change direct queries of the target entity type or other navigations to it.
  • Composition: Apply the predicate before user composition over the navigation, preserving cardinality and operator ordering for Any, Count, projection, ordering and pagination.
  • Loading: Use the same predicate for eager loading, auto-includes, explicit loading, and lazy loading where supported. Define loaded-state and reload behavior.
  • Other filters: Define composition with entity-level query filters and per-query filtered Include; these should normally further restrict the navigation result rather than replace its model-level predicate.
  • Filter bypass: Explicitly define whether IgnoreQueryFilters affects navigation filters and whether a separate bypass mechanism is needed. Do not accidentally inherit bypass semantics from implementation reuse. This feature alone is not an authorization boundary.
  • Tracking and fixup: Define behavior when excluded entities are already tracked or are tracked later. Ordinary relationship fixup must not silently defeat the promised filtered-navigation semantics. Account for the fact that filtered Include currently has tracking/fixup caveats rather than assuming its behavior establishes the desired contract.
  • Mutation: Define whether the filtered navigation is query-only or can update an underlying writable relationship. Adding an entity that fails the predicate, removing a visible entity, or changing a predicate property must have documented behavior. Filtering does not imply deleting excluded rows or making returned entities immutable.
  • Reference navigations: If supported, define what happens when the related row exists but fails the predicate, including null materialization, required relationships, and preservation of the source row.
  • Metadata and validation: Preserve predicates through model finalization and runtime/compiled models where supported; validate unsupported expressions and invalid configuration with actionable diagnostics. Context-dependent values must not leak between contexts through cached models or queries.
Scope and related work
  • #20339 is the parent tracker for flexible navigation mapping.
  • #21991 requested filtered relationship configuration and is a related motivating report.
  • #33171 concerns custom navigation joins/query mappings; this issue specifically adds a predicate to a navigation rather than an arbitrary query source.
  • Separate navigation query/update mappings and read-only navigation semantics are related foundational work, not synonymous with filtering.
  • Mapping navigations to functions, general entity-level filtering, and configuring model-level ordering/pagination are outside this issue's scope.
Lingua principale
C#
Stelle
14.8k
Fork
3.4k
Merge medio
3g 18h
PR unite (30g)
159

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/efcore

Tutte le issue di dotnet/efcore

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.