Model-level Entity Filters

[anpete]

Allow LINQ predicate expressions to be associate with Entity Types in the model. E.g.

modelBuilder.Entity<Customer>().HasFilter(c => !c.IsDeleted); // soft-delete!

Simple, yet powerful feature that can be used to enable many higher-level asks such as Soft-delete, multi-tenancy and filtered Include.

[davidroth]

@anpete I think it would be useful if such filters could be enabled/disabled per context instance or even modified.
If I take the soft-deletion as an example, it is quite common that there is some kind of toggle/switch which enables/disables hiding soft deleted entities in an application/view.

Is this scenario considered?

[anpete]

@davidroth Yes, I was thinking of per-query granularity for disabling them. I'm not sure about modification, though. Filters will be parameterizable via variables in the same way as regular queries, which I think should capture many scenarios. I.e multitenancy.

[colltoaction]

I think this can be achieved pretty nicely with inheritance + discriminators. You can have:

         ClientBase
   +--------+  +-----------+
   |                       |
   v                       v
Client               DeletedClient

modelBuilder.Entity<ClientBase>(entity =>
{
    // ....
    entity.HasDiscriminator(e => e.IsDeleted)
        .HasValue<Client>(false)
        .HasValue<DeletedClient>(true);

The downside compared to a filter would be the boilerplate code needed, but it's also a very flexible model.

[anpete]

Added in b1379b1

[ajcvickers]

Discussed with @divega and it looks like we have two issues tracking this (and a third for DefiningQuery), so closing this as a duplicate of the older issue--that is #5774

[divega]

I think this can be achieved pretty nicely with inheritance + discriminators

@tinchou One problem with this is approach for something like soft-deletes is that it requires mutating the type that a row represents for something that normally should be just a state change. The type is normally considered immutable, similar to the primary key. This is something that in EF Core we made an explicit decision not to block (e.g. discriminator values can be accessed and usually modified), but you have to handle it with care. I am not sure it is a good idea to tie inheritance to this.