EF Core 9 Change Tracking stops working when [Projectable(UseMemberBody=)] is used in an Entity.

[kerimcharfi]

Hi, I'm currently facing the issue that when I use [Projectable(UseMemberBody = nameof(InternalVersionTagString))] on one of the properties in my Entity class, the change tracking of EF CORE 9 stops working completely without errors, even for an unrelated property (e.g. public string? Name { get; set; } )

When using [Projectable] without UseMemberBody the problem does not arise, however this strategy doesnt work well with Hot Chocolate.

    [NotMapped]
    public uint VersionTag { get; set; }

    [GraphQLName("_versionTag")]
    [NotMapped]
    [Projectable(UseMemberBody = nameof(InternalVersionTagString))] <- when i comment this line out, the change tracking works again
    public string VersionTagString { get; set; }
    
    // We have to use this strategy of projectable because Hot Chocolate seems to skip lambdas in their projection engine
    // This leads to the behaviour that e.g. InternalVersionTagString is null until the dependency VersionTag is also fetched
    // The lambda is then used by hot chocolate as a resolver(called after query result arrived), regardless whether it has the [Projectable] Attribute
    private string InternalVersionTagString => VersionTag.ToString();

LOGS

2025-04-08 05:35:26 info: server.api.ItemController[0]
2025-04-08 05:35:26       Old Item name is Tester
2025-04-08 05:35:26 info: server.api.ItemController[0]
2025-04-08 05:35:26       ItemDto name is Testr
2025-04-08 05:35:26 info: server.api.ItemController[0]
2025-04-08 05:35:26       Item name is Testr
....
2025-04-08 05:35:26 info: server.api.ItemController[0]
2025-04-08 05:35:26       ChangeTracker HasChanges before SaveChanges: False

[PhenX]

I think this may be due to this change :
#113

It should not apply "NotMapped" if UseMemberBody is set, what do you think ?

[hahn-kev]

I'm also seeing this issue. I wrote a test like this:

var projectId = Guid.NewGuid();
await _lexBoxDbContext.Projects.Where(p => p.Code == "test1").ExecuteDeleteAsync();
_lexBoxDbContext.Projects.Add(new Project
{
    Id = projectId,
//...
});
await _lexBoxDbContext.SaveChangesAsync();

_lexBoxDbContext.ChangeTracker.Clear();
_lexBoxDbContext.ChangeTracker.Entries().Should().BeEmpty();

var project = await _lexBoxDbContext.Projects.AsTracking().SingleOrDefaultAsync(p => p.Id == projectId);
project.Should().NotBeNull();

var entityEntry = _lexBoxDbContext.ChangeTracker.Entries().Should().ContainSingle().Subject;
// entityEntry.Entity.Should().BeSameAs(project);//fails here
_lexBoxDbContext.Projects.Remove(project);//fails here saying project can't be tracked as another instance is already tracked.
await _lexBoxDbContext.SaveChangesAsync();
project = await _lexBoxDbContext.Projects.FindAsync(projectId);
project.Should().BeNull();

for some reason projectables is breaking the change tracker by returning a different object than was stored in the change tracker.

This seems to be an issue for 4.0.0, and exists when using EF 9 and EF 8.

[hahn-kev]

Update. I wrote a unit test for Projectables like this:

public class ChangeTrackerTests
{
    public class SqliteSampleDbContext<TEntity> : DbContext
        where TEntity : class
    {
        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlite("Data Source=test.sqlite");
            optionsBuilder.UseProjectables();
        }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity<TEntity>();
        }
    }
    public record Entity
    {
        public int Id { get; set; }

        [Projectable(UseMemberBody = nameof(InternalComputed1))]
        public int Computed1 { get; set; }
        private int InternalComputed1 => Id;

        [Projectable]
        public int Computed2 => Id * 2;
    }

    [Fact]
    public async Task CanQueryAndChangeTrackedEntities()
    {
        using var dbContext = new SqliteSampleDbContext<Entity>();
        await dbContext.Database.EnsureDeletedAsync();
        await dbContext.Database.EnsureCreatedAsync();
        dbContext.Add(new Entity());
        await dbContext.SaveChangesAsync();
        dbContext.ChangeTracker.Clear();

        var entity = await dbContext.Set<Entity>().FirstAsync();
        var entityEntry = dbContext.ChangeTracker.Entries().Single();
        Assert.Same(entityEntry.Entity, entity);//fails meaning that what we got isn't tracked so we can't update it.
        dbContext.Set<Entity>().Remove(entity);
        await dbContext.SaveChangesAsync();
    }
}

it fails at the assert, but also fails at the remove with an error about it already being tracked.

I went through history and the test passes on 24dcbb7 (#87) and fails on 4a83905 (#86). So it looks like #86 broke this.

[hahn-kev]

Just to confirm the issue, I went in to ProjectableExpressionReplacer and set _disableRootRewrite to true and that made the test pass.

I'm not really sure what the fix is here. I think the issue is that EF doesn't track results when Select is used (rightfully so). Which means while await dbContext.Set<Entity>().FirstAsync(); returns the tracked Entity, dbContext.Set<Entity>().Select(e => new Entity(){Name = e.Name, Id = e.Id, Computed1 = e.Computed1}).FirstAsync() does not. There's a couple ways to solve this I suppose. One is that the library could determine if tracking was desired. Eg if I do await dbContext.Set<Entity>().AsNoTracking().FirstAsync() then it's fine to rewrite the root. But if I did await dbContext.Set<Entity>().AsTracking().FirstAsync() then you can't rewrite the root. This obviously depends on the default tracking also. At the very least being able to opt in to root rewrite at the global level and at the query level would be very useful, otherwise EF is not usable the way this works right now.

Edit: let me know what you think, I've got a PoC which uses the tracking behavior to determine if it should rewrite the root or not.