Index attribute on BaseEntityTableData prevents CosmosEntityTableData with CosmosDB EF Provider

[richard-einfinity]

Describe the bug

Index attribute on BaseEntityTableData prevents CosmosEntityTableData with CosmosDB EF Provider. Context throws System.InvalidOperationException. The entity type 'ModelName' has an index defined over properties 'UpdatedAt,Deleted'. The Azure Cosmos DB provider for EF Core currently does not support index definitions.

To Reproduce

Steps to reproduce the behavior:

Define Models based on CosmosEntityTableData
Add Models to Context and perform entity configuration.
Call await dbContext.Database.EnsureCreatedAsync();

Expected behavior

Database and containers to be created in CosmosDB

What platforms?

Note: Any bug or feature request that is opened for an unsupported environment will be automatically closed.

• Server:
  • Version of dotnet being used to compile? net8
  • Library versions? CommunityToolkit.Datasync.Server.EntityFrameworkCore 8.0.4.
  • What database are you using? CosmosDB
  • Where are you running the server? Azure

Additional context

Worked around by creating a new CosmosEntityTableData base model inheriting from ITableData directly.

[adrianhall]

Do you have a minimal repro that I can look at?

[richard-einfinity]

I'll put together a repo based on the Todo Sample. There's a few other issues that have come up which will be a problem for 9.0. I'll document them separately. But just as a quick note, In the TableController.Query.cs there's a comment mentioning calling ToListAsync but the call is actually ToList in the client evaluation function. Do these methods need to be made Async?

[richard-einfinity]

@adrianhall apologies this issue is related to EF9. EF8 ignores index definitions as their not mapped where EF9 throws if an index is defined.

Maybe bump to 9.0

[adrianhall]

I'm not sure I can continue to support the Cosmos database.

The repository pattern relies on the fact that we can get an IQueryable for the dataset. In fact, this is a requirement of the OData library. When we do query.ApplyTo(), it executes .ToList() underneath. Without this, we don't have a viable way of supporting query semantics within the service without re-writing OData AND converting all the other repository types (except for EF Core). Basically, we would become an EF Core only provider.

Will talk to the person who owns EF Core Cosmos driver on this - it's on hold right now. But this is a seriously large breaking change that has obviously not been thought through.

[richard-einfinity]

Hi Adrian,

Did you see the code sample I included on #184? Delaying applying PageSize and $select to later avoids the sync call. And allows you to call the async on the IQueryable.

Retrieving the IQueryable seems to be fine. When $select is applied in the current implementation is where it all seems to go wrong.

For now I've created a cosmos specific repository works well and suits my needs.

If we can get both the calls in the query action to async I think it would go a long way.

EF9 will automatically recognise Partition keys defined on the IQueryable so no additional work needs to be done there as the views can be applied in the IAccessControlProvider.

Could the index attribute be moved further up to the other TableData subclasses?

I'll publish some code up to my fork.

[adrianhall]

I did - I’m still working through the details, and working with both the OData library engineers and EF Core team. We’ll get a suitable solution.