Efcore: Discuss incorporating in-memory helpers functionality

[divega]

Per the discussion at https://twitter.com/rothdave/status/1022775345471254529?s=20, see https://github.com/SimonCropp/EfCore.InMemoryHelpers. This wraps in-memory provider to make it more like relational in a few aspects like value generation, referential constraints and concurrency control.

[divega]

@SimonCropp we discussed this briefly after triage today.

If you or anyone are willing to send contributions to implement similar functionality we would consider them.

Our stance on in-memory has evolved over time. Although we still see potential pitfalls in anyone assuming that in-memory is going to behave exactly like a real (e.g. relational) database, these specific improvements seem to just make it more useful.

If we took these changes, we would need to also consider the potential breaking impact and decide if we need to mitigate them.

[SimonCropp]

Can someone from the ef team review my implementation and comment if my approach to solving any of those problems is suitable to be pushed into the core code base?

To save me doing a pr that is a flawed approach

[ajcvickers]

@SimonCropp I took a look at the code and I think it would need some changes to be appropriate for the EF Core codebase. In general, these are more like workarounds in a NuGet package, which is great since it let's people get at them easily, but the layering, API surface, and some of the implementation would need to be different to fit into the product architecture. Some examples:

• Value generation for keys should be part of the in-memory database implementation, and should not need any interaction to reset the value. It should not be shared between databases, and should be reset when the database is deleted and a new database is created.
• Constraint checking should again be part of the in-memory database, not something that is integrated with the state manager.
• Rowversion-like concurrency checking could also be specifically part of the in-memory database. However, it would be more generally useful to implement optimistic offline locking in a way that is not specific to the in-memory provider, since it could then be used by other providers for which the database does not natively support this type of functionality.

We would of course be super happy if you chose to send PRs for these things, but of course it's a lot more work than just porting the existing code over.

/cc @divega