Bulk updates/deletes: Support in-memory provider

[Sebazzz]

For unit testing it would be great if the in-memory provider could also support bulk updates and deletes from #795, as this simplifies testing greatly.

Currently it fails with a rather obscure error message:

System.InvalidOperationException : The LINQ expression 'DbSet<Source>()
    .Where(s => s.CopiedFromId == __source_Id_0)
    .Select(s => IncludeExpression(
        EntityExpression:
        IncludeExpression(
            EntityExpression:
            IncludeExpression(
                EntityExpression:
                s, 
                NavigationExpression:
                EF.Property<UserMetadata>(s, "CreatedBy"), CreatedBy)
            , 
            NavigationExpression:
            EF.Property<UserMetadata>(s, "LastModifiedBy"), LastModifiedBy)
        , 
        NavigationExpression:
        EF.Property<OwnershipMetadata>(s, "OwnedBy"), OwnedBy)
    )
    .ExecuteUpdate(action => action.SetProperty<int?>(
        propertyExpression: s => s.CopiedFromId, 
        valueExpression: _ => null))' could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to 'AsEnumerable', 'AsAsyncEnumerable', 'ToList', or 'ToListAsync'. See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.
   at Microsoft.EntityFrameworkCore.Query.QueryableMethodTranslatingExpressionVisitor.VisitMethodCall(MethodCallExpression methodCallExpression)

Note that this owned type is also included in the expression tree apparently, which makes it even more difficult to understand.

[roji]

@Sebazzz it's very unlikely that we would implement this; the InMemory provider cannot implement all the features of a relational database, and is generally unsuitable as a testing double (fake). See this overview, or, for more depth, this page.

[Sebazzz]

@roji One piece of feedback I'd like to give: The InMemory provider has the advantage of (1) ease of use (no set-up needed), and (2) it does not enforce many of the constraints a Sqlite or SqlServer database would. That makes it extremely useful for unit tests in CSRF/Clean Architecture scenarios for instance.

If it was possible to create a Sqlite in-memory database, but with the same behaviour as in-memory - I'd use it in an instant and that would make the InMemory provider obsolete for me.

[roji]

@Sebazzz what kind of constraints does SQLite in-memory have that make InMemory a better choice for you?

[Sebazzz]

@roji Think like required fields and navigation properties for instance (though strangely in some cases the InMemory provider also wants some fields for instance, mostly on string fields). I can just "save" a few entities and don't need to bother with a lot of these constraints and I got my set-up for a test.

[roji]

@Sebazzz you should be able to bulk-configure your model to make all properties nullable when SQLite is used, or something similar. Though I'm not sure it's a great idea to be leaving properties/columns empty when in your real application they can't be nullable (regardless of InMemory vs. SQLite) - generally you want your testing model to approximate your real one.