Add Option to InMemoryDB to ignore Relational-specific methods

Problem

We are using the InMemoryDatabase to test all our business logic. Now we have this one place where we need to ExecuteSqlRaw (to enable identity insert).

Of course we get the System.InvalidOperationException : Relational-specific methods can only be used when the context is using a relational database provider. exception.

I know this issue popped up in the past several times - I guess with migrations. I myself run into this issue several times over the years.

Solution

I think it would be nice to have an option for the InMemoryDatabase to just silently ignore Relational-specific method calls instead of throwing this exception. The InMemoryDatabase already ignores so many relational-specific things like foreign keys or schema checks (not null, max length, etc.) so it doesn’t seem totally inappropriate to have such an option. Default disabled.

The InMemoryDatabase is a great tool for testing and this would make it even more useable.

[ajcvickers]

@matthiaslischka As @roji said, we discussed this as a team and we believe things like this are exactly why using the in-memory provider for testing is an anti-pattern. We don’t plan to change the in-memory provider in the way you suggest. Instead, take a look at the documentation that @roji pointed to and consider using a relational provider for your testing.

[roji]

Thanks, we’ll discuss this as a team and see what we think.

FWIW we do have an explicitly documented consensus that InMemory is not a good choice for testing EF Core applications (see the docs). Either you want to completely mock out your data layer and test your business logic - in which case a repository pattern is the right layer to mock (and avoid issues such as raw SQL) - or you want to exercise your data layer, in which case you should ideally be testing against your production database system. In our experience many people end up using InMemory because they think running tests on SQL Server or other production databases isn’t feasible, and that isn’t really true.