Support configuring a model-level filter on a navigation

Abierto
  • ¿Algo no está bien?
#39,421 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp
Área
database

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
C#
Estrellas
14.8k
Forks
3.4k
Merge medio
3 d 18 h
PR fusionados (30 d)
159

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/efcore

Todos los issues de dotnet/efcore

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.