The Cosmos provider ignores configured indexes

[ajcvickers]

For example:

modelBuilder.Entity<Book>().HasIndex(e => e.ByteArray);

This will currently pass model validation, but the index is ignored. We should fail for this in model validation.

[roji]

Or implement it ;)

[ajcvickers]

Or implement it ;)

I could be wrong, but I don't think a naked .HasIndex call will ever do anything on Cosmos. You're going to need to chain something (like ForVectors) to specify how it will be used in the index specification.

[roji]

This definitely would require more thinking... You know more than me, but it seems like it could make sense to apply a Cosmos indexing policy that includes paths only to the properties on which HasIndex() has been called, no? One big difference from relational is that in relational, there are no indexes by default, whereas in Cosmos everything seems to be indexed by default, and the policy is more of a way to do finer-grained tweaking to only index specific properties.

In any case, probably not for 9.0, so yeah, validating against HasIndex() at this point sounds like the right thing indeed...

[roji]

See #32517 for enabling proper support for HasIndex() on Cosmos.

[toiyabe]

This has caused an unforeseen problem with by project. See #35264
Instead of throw an exception, how about throw a warning?

[hades200082]

Another use-case for being able to include HasIndex would be in situations/applications where you want to allow the person installing your software to choose which database provider they wish to use.

Since EF Core supports SQL and NoSQL databases now, including CosmosDB it would make sense to ensure that developers can use all of the features & functionality of EF Core in their apps without restricting it with exceptions and other errors/warnings based on the specific provider.

My end customer should be able to install my software and select SQL Server, Postgres or Cosmos and EF Core should be able to handle it (as long as I don't do any direct usage of the database/SQL myself).