Problem with Expression index

[objectOlolo]

I am triing to ensure that my context is synced with external schema. I am triing to scaffold context, but ef failed with error about expression index.

Expression index 'ux_bla_bla' on table private.awesome_table cannot be scaffolded, expression indices aren't supported and must be added via raw SQL in migrations.
System.NotImplementedException: The method or operation is not implemented.

I can't drop that index because of ther reasons and i can't skip it (or i don't know how)
Could you pls provide some flag or method to complete scaffold with warning about skipped objects or allow to skip em manually?

i am usin "dotnet ef dbcontext scaffold" command

[smitpatel]

@WhoStoleMyNick - Are you using EF Core? I am not able to find any place in this codebase which throws exception message like that.

[objectOlolo]

at Microsoft.EntityFrameworkCore.Scaffolding.ProviderCodeGenerator.GenerateUseProvider(String connectionString)
   at Microsoft.EntityFrameworkCore.Scaffolding.Internal.CSharpDbContextGenerator.GenerateOnConfiguring(String connectionString, Boolean suppressConnectionStringWarning)
   at Microsoft.EntityFrameworkCore.Scaffolding.Internal.CSharpDbContextGenerator.GenerateClass(IModel model, String contextName, String connectionString, Boolean useDataAnnotations, Boolean suppressConnectionStringWarning)
   at Microsoft.EntityFrameworkCore.Scaffolding.Internal.CSharpDbContextGenerator.WriteCode(IModel model, String namespace, String contextName, String connectionString, Boolean useDataAnnotations, Boolean suppressConnectionStringWarning)
   at Microsoft.EntityFrameworkCore.Scaffolding.Internal.CSharpModelGenerator.GenerateModel(IModel model, String namespace, String contextDir, String contextName, String connectionString, ModelCodeGenerationOptions options)
   at Microsoft.EntityFrameworkCore.Design.Internal.DatabaseOperations.ScaffoldContext(String provider, String connectionString, String outputDir, String outputContextDir, String dbContextClassName, IEnumerable`1 schemas, IEnumerable`1 tables, Boolean useDataAnnotations, Boolean overwriteFiles, Boolean useDatabaseNames)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.ScaffoldContextImpl(String provider, String connectionString, String outputDir, String outputDbContextDir, String dbContextClassName, IEnumerable`1 schemaFilters, IEnumerable`1 tableFilters, Boolean useDataAnnotations, Boolean overwriteFiles, Boolean useDatabaseNames)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.ScaffoldContext.<>c__DisplayClass0_1.<.ctor>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)

Yep

[smitpatel]

Which database provider? And which version?

[objectOlolo]

Npgsql.EntityFrameworkCore.PostgreSQL 2.2.4

[objectOlolo]

Wrong project?(

[smitpatel]

cc: @roji

@WhoStoleMyNick - Are you using EF Core 2.2 or EF Core 3.0?

[objectOlolo]

2.2. I guess if i use 3.0 version of provider would be 3.0+

[smitpatel]

Was just making sure that we are not mixing package versions. Given the stack trace, it seems to me that the method is not just implemented (so again some issue in mixed package version), expression indices is just a warning and it is being skipped but something else is causing error. NpqSql provider repo would be correct place for this issue.

[objectOlolo]

Oops, i change target framework of csproj from 2.1 to 2.2 and get
Expression index 'ux_bla_bla on table private.awsome_table cannot be scaffolded, expression indices aren't supported and must be added via raw SQL in migrations.
and context generats successfully, sorry my fault, thanks for fast responce.

[objectOlolo]

Context was generated with warn as expected.

[roji]

@WhoStoleMyNick yeah, as the exception message says, the Npgsql EF Core provider doesn't support expression indices in any way. This is tracked by npgsql/efcore.pg#119 and hopefully will happen one day. But you can still set them up via raw SQL in your migrations, so this shouldn't be blocking.