Support separate navigation query and update mappings, including read-only navigations

Đang mở
  • Có gì không ổn?
#39,422 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp
Lĩnh vực
database

Hướng nghiên cứu

Start with the parent tracker #20339 and the related issues #20337 and #33171 to understand how this work is divided. The issue calls for design across navigation metadata, query translation and loading, change tracking, model finalization, and compiled models; no specific files or tests are named. Done means defining and implementing query-only and separate query/update navigation mappings with clear mutation behavior and lifecycle support.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

area-model-building area-query area-save-changes needs-design

A navigation used to query related entities does not always represent an association that can be changed by assigning the reference or adding/removing collection elements. Its query mapping may also differ from the target entity type's normal query source or from the relationship used to persist association changes.

Similarly, a model may expose both a read-only relationship and a derived, writable navigation to the same target entity type. These navigations need different query semantics without inventing additional persistence relationships.

Current ordinary navigation metadata is tied to a foreign key. Navigation mutation and relationship fixup operate on that relationship. This does not provide an independent contract for a query-only association.

Existing support and workarounds

EF already supports some separation at the entity-type level: an entity can be queried through a view and updated through a table. This issue should preserve and build on that behavior, not reintroduce it as a new feature.

However, entity-type table/view mapping does not independently describe how a particular navigation is queried or whether mutations to its association can be persisted.

Neither a getter-only property nor IReadOnlyCollection<T> establishes this semantic distinction. EF can populate navigations through backing fields and collection accessors, and CLR API shape alone does not specify persistence behavior. Likewise, AsNoTracking controls tracking of query results rather than declaring an association read-only.

Explicit LINQ queries/projections can compute derived associations today, but do not provide a reusable mapped navigation with ordinary loading semantics.

Describe the solution you'd like

Separate the metadata and behavior used to query a navigation from the relationship/update mapping used to persist changes to its association.

Allow an explicitly configured query-only navigation with no association update mapping. Allow an independently configured update mapping where a persistable relationship exists. The exact configuration API and supported combinations need design.

"Read-only navigation" should mean that EF does not infer or persist association changes from that navigation. It should not mean that the returned entity instances are necessarily read-only, keyless, or untracked.

Design considerations
  • Query mapping: Describe navigation query semantics independently of the target entity type's default mapping and of any writable relationship. Query translation and loading must consistently honor that mapping.
  • Association mutation: Define what happens when a read-only reference is assigned or a read-only collection is changed, including changes made through backing fields or the change-tracking API. Unsupported attempts to persist association changes should have explicit diagnostics rather than silently succeeding or changing another relationship.
  • Materialization and fixup: EF must still be able to populate query-only navigations. Distinguish internal materialization/fixup from application mutation. Define whether and how already-tracked entities participate; fixup must not populate a derived navigation using only the target's ordinary foreign-key relationship.
  • Entity updates: Returned keyed entities can retain their normal update mapping. Updating their scalar properties should not require the navigation association itself to be writable.
  • Relationship side effects: Query-only associations must not introduce synthetic foreign keys, join tables, cascade deletes, orphan deletion, or ownership semantics merely to represent their query behavior.
  • Consistency: Define loaded-state and reload behavior when source or target properties affecting membership change. Do not imply that arbitrary database-defined associations can always be maintained automatically in memory.
  • Writable mappings: When both query and update mappings exist, define how reference/collection changes affect the writable relationship, including inverse navigations, and how discrepancies between queried membership and writable membership are handled.
  • Metadata lifecycle: Preserve configuration through conventions, model finalization, runtime/compiled models and snapshots where applicable. Query-only metadata should not produce spurious schema operations.
Scope and related work
  • #20339 is the parent tracker for flexible navigation mapping.
  • #20337 tracks a specific consumer: implicit many-to-many associations without a join table.
  • #33171 tracks custom joins/query mappings for read-only navigations. This issue supplies the query/update separation and mutability contract, rather than the syntax or translation of arbitrary joins.
  • Mapping navigations to database functions is another consumer of this separation and should have its own focused tracker under #4319/#20339.
  • General immutability of entity instances, new query-source forms, and automatic in-memory reevaluation of arbitrary queries are not required by this issue.
Ngôn ngữ chính
C#
Star
14.8k
Fork
3.4k
Merge trung bình
3 ngày 18 giờ
Pull request đã merge (30 ngày)
159

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/efcore

Tất cả issue của dotnet/efcore

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.