Allow named in-memory stores

[ajcvickers]

We decided in API review to remove the "persist" flag from the in-memory provider and replace with a string that could be used to create a named in-memory store. However, we were pretty much never using the persist: false anyway, so I just removed it and created a bug to triage adding named databases so we could triage appropriately.

[rowanmiller]

At the moment, do you get one per ServiceProvider, or one per context type per ServiceProvider? Either way, I don't think we need the named database capability for RC.

[ajcvickers]

You get one table per entity type per service provider.

[rowanmiller]

Reactivating (presumably for the backlog) as I am writing the docs for in-memory testing and this is not very easy at the moment. I think named instances could be a good solution to avoid folks having to muck around with ServiceCollections.

[NeilCross]

Sorry for bringing up an old thread, but currently the Testing with InMemory in the EF docs:
mentions requiring a workaround to this issue.

Caution
Currently you need to use ServiceCollection and IServiceProvider to control the scope of the InMemory database, which adds complexity to your tests. In the next release after RC2, there will be improvements to make this easier, see issue #3253 for more details.

Now 1.0.0 is released and I assume this warning in the docs not required anymore, and a ServiceCollection is no longer required to instantiate an in-memory context
Can you confirm this for me?

I'm assuming the simplest way to instantiate an in-memory context now is:

var builder = new DbContextOptionsBuilder();
builder.UseInMemoryDatabase();
var context = new BloggingContext(builder.options)

[rowanmiller]

@NeilCross opened dotnet/EntityFramework.Docs#287 to fix the docs. The docs are currently migrating to a new system, so I'll fix once the migration is done.

[NeilCross]

Good to know, thanks Rowan.

[logamanig]

Following code works perfectly for me,
// Requires separate DI Service provider to isolate db instance as InMemory database is also shared within
// the class scope since the App Service Factory is configured to per scope instance for dbcontext
var internalServiceProviderForDbContext = new ServiceCollection()
.AddEntityFrameworkInMemoryDatabase()
.BuildServiceProvider();
var options = new DbContextOptionsBuilder()
.UseInternalServiceProvider(internalServiceProviderForDbContext)
.UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString())
.Options;

[ajcvickers]

@logamanig It's generally best to avoid calling UseInternalServiceProvider if you don't really need to.

[logamanig]

@logamanig It's generally best to avoid calling UseInternalServiceProvider if you don't really need to.

without calling UseInternalServiceProvider, not able to isolate the InMemoryDatabase instance between test cases. Just a unique database name is not enough to isolate.

[ajcvickers]

@logamanig There are other ways to deal with that that aren't such a heavy hammer:

• Figure out why the internal service provider is being built differently for different uses of the context--look at the logging
• Specify the database root in UseInMemoryDatabase

Also, in 3.0 is is less likely you will run into this case at all.

[logamanig]

Thanks @ajcvickers !
as you suggested, specifying the database root avoids internal service provider heavy lifting..
here's the sample code,

var options = new DbContextOptionsBuilder<DbContextClass>()
                .UseInMemoryDatabase(
                    databaseName: Guid.NewGuid().ToString(),
                    databaseRoot: new InMemoryDatabaseRoot()
                    )
                .Options;