Conflict with __EFMigrationsHistory table in schema other than public

Given two DbContexts each with their own default schema, Let’s say ContextOne with the default schema of public and ContextTwo with an alternate schema of, say, example, I cannot use both DBContexts in the same database without overriding the default table name of the migrations history table.

The culprit appears to be this SQL that searches for the migration history table:

SELECT EXISTS (SELECT 1 FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON n.oid=c.relnamespace WHERE c.relname='__EFMigrationsHistory');

This will return a result if the __EFMigrationsHistory table exists in any schema. So, if, say, ContextTwo runs its migrations first, creates its __EFMigrationsHistory table in its schema of example, then ContextOne runs its migrations, the above SQL falsely reports that its __EFMigrationsHistory table exists. The migrations then fail because the inserts into the migration history table (assumed to be on the default public schema) attempt to insert into a table that doesn’t exist.

The workaround that I’ve used is to override the migration history table’s name such that it’s unique across all schemas.

[floyd-may]

We’re likely to skip 2.2 and go straight to 3.0 given the dependency rats nest that is ASP.Net Core 2.2 that they’ve hopefully fixed in 3.0. Thanks for the hard work y’all put into this project!!!

[roji]

@floyd-may I understand but could not reproduce the issue: I successfully created two contexts with the same migration history table name - but different schemas - and I can see both in the database. The query I’m seeing is:

SELECT EXISTS (SELECT 1 FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON n.oid=c.relnamespace WHERE n.nspname='foo' AND c.relname='__CrapMigrations')

Can you please test on v2.2 to see if the problem goes away, and if not, post exact, detailed step-by-step instructions on how to reproduce the issue?