DatabaseCreator - Check for tables from model rather than just any models.

[hkoestin]

When having two different DbContext instances, e.g. A and B, both having different tables, e.g. A has a1 and a2, B has b1 and b2, a call to context.Database.EnsureCreated() does not really work, when both of the context instances point to the same physical DB.

Only the tables of the first context will be created in the database. The tables from the second context will be ignored. Thus, the first action on the second context usually fails with an exception, that certain objects/tables do not exist.

So, if you call contextA.EnsureCreated() first, tables a1 and a2 will be created. That is fine. However, when you want to use the same DB for contextB as well, contextB.EnsureCreated() will not work anymore, because the "HasTables" method will simply say "true", because there are OTHER tables (namely a1 and a2 from context A) existing in the DB, but not b1 and b2.

The creator should also work in this case in my opinion.

HasTables should check, if the tables for the CURRENT context-model are given or not.
CreateTables should then create the tables for the CURRENT context, if needed.

Would this be possible?
Is this actually possible without any big side-effects?

See also similar issue for SQL CE:
ErikEJ/EntityFramework.SqlServerCompact#205

[rowanmiller]

Agreed we could improve here. We aren't going to do this for our November release, so putting into backlog.

[benharden]

Does this issue mean there is no support for multiple contexts when using the same database throughout EF7 or is it just an issue with the relational provider?

You say that this won't be included in the November release, but will support for this be included in the Q1 2016 release?

[thisispaulsmith]

Has there been any movement on this? EnsureCreated still only checks if the database exists if it does no tables are checked.

[ajcvickers]

@thisispaulsmith I have cleared the milestone so we can discuss in triage. These APIs are on purpose designed to be very simple because their only intended use if for testing or quick prototyping. Migrations should be used for anything else. That being said, we could make EnsureCreated create the tables if and only if none of the tables that would be created already exist. I don't think we would ever go any further than that, and even that may be a step too far, especially when considering the semantics for non-relational providers.

[thisispaulsmith]

@ajcvickers Thanks.
I was trying to use it in an integration test. Two contexts using the same DB. Discovered it when using the second context failed. Not a huge issue but I noticed the issue was quite old.

[ajcvickers]

Discussed this in triage and decided that we want to keep EnsureCreated and EnsureDeleted as a pair of methods with very simple semantics. That is, if the database doesn't exist or is completely empty, then create it for EnsureCreated, and always wipe it completely clean for EnsureDeleted.

@thisispaulsmith Look into using IRelationalDatabaseCreator.CreateTables for what you want to do.

[imranbaloch]

@ajcvickers what about InMemory as InMemoryDatabaseCreator does not contains CreateTables