Enable configuring default/computed property values with a lambda expression

[divega]

The main purpose of this feature is to simplify implementing the write side of the multi-tenant scenarios using a declarative approach in the model. Currently you do this writing some imperative code in an override of SaveChanges.

This could be a new overload of HasDefaultValue that allows passing a Expression<Func<T>> (or even a Func<TDbContext, T> if we are ok with drifting from the pattern used by query filters).

This would enable obtaining the value from the actual DbContext instance used at SaveChanges time.

Example:

modelBuilder.Entity<Blog>()
    .Property<string>("TenantId")
    .HasField("_tenantId")
    .HasDefaultValue(() => _tenantId);

This should save you from having to write this kind of code:

        public override int SaveChanges()
        {
            ChangeTracker.DetectChanges();

            foreach (var item 
                in ChangeTracker.Entries()
                    .Where(e => e.State == EntityState.Added 
                             && e.Metadata.GetProperties()
                                   .Any(p => p.Name == "TenantId")))
            {
                item.CurrentValues["TenantId"] = _tenantId;
            }

            return base.SaveChanges();
        }

cc @anpete

[AndriySvyryd]

Also consider doing it for all relevant metadata APIs at the same time (default value, computed value, check constraint...).

[TonyValenti]

I wanted to post here and say that I could really use this feature as well.

In our scenario, we pull data from JSON APIs and cache the responses in a SQLite table. When we do, we cache the raw JSON in a column but also store important properties in their own columns.

It would be nice to not have to manually map the important properties from the JSON object to the table on add and update and instead be able to let EFCore handle this for us.

[roji]

It would be nice to not have to manually map the important properties from the JSON object to the table on add and update and instead be able to let EFCore handle this for us.

Note that this issue doesn't remove the need to "manually" map your properties; it only allows you to do it via a LINQ expression instead of via SQL.

[TonyValenti]

Yes. You are correct. I'd like to do the mapping once when I configure the context and have it automatically re-apply whenever the source data changes.

[roji]

So again - you're already able to do that by configuring a computed column as usual, and specifying raw SQL in the computed column definition which fetches data from column (e.g. with the JSON_VALUE() function). The only thing this issue tracks is allowing you to express that definition via LINQ, as opposed to via raw SQL. There's nothing here you can't already do.

[TonyValenti]

I am hopeful that when this gets implemented, I will be able to express computed properties as provider independent C# expressions as opposed to provider-dependent SQL scripts.

[lucaslorentz]

Hey, just want to share that for a few weeks I've working on auto-updated "computed properties" in EF Core: https://github.com/lucaslorentz/computed-expression. Unofficial project!

It doesn't solve the issue reported by @divega, but seems a good fit for @TonyValenti use case
It is still in pre-release, but I would appreciate some early testing and feedback if it is useful and working properly.

[TonyValenti]

Hi @lucaslorentz -
This looks like exactly what I'd be wanting.

Does this allow calling custom functions and such in the computed property expression?