Recognize filters created by fluent API and reverse engineer to fluent API.

I define a unique index for a entity Folder with a nullable property Folder.FolderId (link to parent folder)

modelBuilder.Entity<Folder>().HasIndex(f => new { f.Name, f.FolderId }).IsUnique();

The debugger shows a Relational:Filter “[FOLDER_ID] IS NOT NULL” annotation defined on that index. The generated DDL looks fine

CREATE UNIQUE INDEX [IX_FOLDERS_NAME_FOLDER_ID] ON [ICNG].[FOLDERS] ([NAME], [FOLDER_ID]) WHERE [FOLDER_ID] IS NOT NULL;

Now if I reverse engineer this database

var reporter = new TestOperationReporter();
var svcColl = new ServiceCollection()
    .AddLogging()
    .AddSingleton<IOperationReporter>(reporter)
    .AddScaffolding(reporter);
new SqlServerDesignTimeServices().ConfigureDesignTimeServices(svcColl);
IServiceProvider prov = svcColl.BuildServiceProvider();

var scaffoldingModelFactory = prov.GetService<IScaffoldingModelFactory>();
var scaffoldedModel = scaffoldingModelFactory.Create(
    ConnectionString,
    Enumerable.Empty<string>(),
    Enumerable.Empty<string>(),
    true);

then the Relational:Filter becomes “([FOLDER_ID] IS NOT NULL)” (note the two round brackets). Diffing the original and the scaffolded models yields unnecessary DROP/CREATE INDEX operations, which at first glance doesn’t look correct. Wouldn’t it make sense to reduce the Relational:Filter to a canonical form during scaffolding?

Further technical details

EF Core version: 2.0.0 Database Provider: Microsoft.EntityFrameworkCore.SqlServer Operating system: Windows 10 Pro IDE: Visual Studio 2017

[bricelam]

Unfortunately, reducing expressions returned by the database requires parsing Transact-SQL. We tried this in the past, but it was very error-prone, so we decided to avoid doing it for now.

From what I remember, the parenthesis were actually required in certain cases, so we couldn’t just blindly strip them from every expression.

[bricelam]

Today, the provider doesn’t play a role in deciding whether “core” configuration would be applied by convention. We need to add additional provider APIs to enable this.