Take advantage of ownership to enable aggregate behaviors in model

Open
#1,985 20 comments 43 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
csharp
Domain
databases

Research direction

Start by reviewing the linked backlog issues, especially #10179, #12168, #10551, and #18529, to determine which aggregate behavior is in scope. The issue names no implementation files or tests, and completion criteria for the overall epic are not defined; a concrete linked issue would be needed before work can begin.

Written by the indexing model from the issue text.

Description

area-model-building area-owned-entities composite-issue needs-design

This is a grouping of related issues. Feel free to vote (👍) for this issue to indicate that this is an area that you think we should spend time on, but consider also voting for individual issues for things you consider especially important.


This an "epic" issue for the theme of automatic aggregate behaviors in the model based on ownership. Specific pieces of work will be tracked by linked issues.

Backlog
  • A delete orphans/cascade delete policy an can be applied by convention to owned entities #10179
  • For example, we could implement client-only cascade delete for aggregates, which should be fully loaded and hence won't have issues with some entities needing to be deleted in the store. However, also consider that an aggregate cannot have true cycles, and hence the SQL Server limitation might not be as bad. #12168
  • A cascade update could also be applied #10551)
  • Smarter logic can be applied to infer the intended state of objects while merging a detached graph into a context: non root objects within the aggregate that are no longer reachable can be marked as deleted, while non root objects that appear for the first time within the aggregate being merged can be marked as added. The same assumptions can't be made with the same confidence across aggregate boundaries. This could be handled by a new method: 'Merge()' (related to #5536)
  • Concurrency control could be delegated to the aggregate root when it's not mapped to the same store object #18529
  • #12078
  • Allow to configure an owned navigation as lazy
  • #15936
  • Decide how null owned properties are handled by SaveChanges #24581
  • Shouldn't DbContext.Update() result in commands to delete (set all null) an entity's owned type navigation property if it is null? #26493
  • #13890
  • #11336
  • #26505

Original issue

Define included properties

When you get an entity from the database and you also want to get a "child entity", you need to pass that "child object" as an expression in order to also get it from the database (when not using lazy loading).

public class Parent
{
    public Child Child { get; set;}
}
public class Child
{   
}

var dataContext = new DataContext();
var parents = dataContext.Parents.Include(p => p.Child).ToList();

Would it be possible to add an new attribute that will be read by the datacontext and add the include statements automatic?

public class Parent
{
   [Include]
    public Child Child { get; set;}
}
public class Child
{   
}

var dataContext = new DataContext();
var parents = dataContext.Parents.ToList();  // Child entity is also read from the database
Dominant language
C#
Stars
14.8k
Forks
3.4k
Avg merge
2d 5h
Merged PRs (30d)
134

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/efcore

All issues in dotnet/efcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.