Huh, spent quite a lot of time on a problem with separate DB contexts for each DB schema, hope that it will help somebody else...
I recently started working on a project that had one database with 3 schemas (DB first approach), one of them for user management. There was a DB context scaffolded from each separate schema. Of course, users were related to other schemas as well, eg. schema KB had a table Topic, which had "created by", "last modified by" etc. FK to identity schema, table appuser.
These objects were loaded separately in C#, firstly, topic was loaded from 1 context, then users were loaded via user IDs from the other db context - not nice, have to fix this!
(similar to using multiple dbcontexts in the same database with EF 6)
First, I tried to add missing FK instructions from identity schema to KB schema, to EF modelBuilder in KB DB context. The same as if there was only 1 context, but I separated it to 2.
modelBuilder.Entity(entity =>
{
entity.HasOne(d => d.Creator)
.WithMany(p => p.TopicCreator)
.HasForeignKey(d => d.CreatorId)
.HasConstraintName("fk_topic_app_users");
It didnt work, because kb db context didn't have any information about the user object, postgres returned error relation "AppUsers" does not exist. Select statement didnt have proper information about schema, field names etc.
I almost gave up, but then i noticed a switch "-d" when running dotnet ef dbcontext scaffold. Its short for -data-annotations - Use attributes to configure the model (where possible). If omitted, only the fluent API is used.
With this switch specified, object properties were defined not in db context OnModelCreating(), but rather on the object itself, with attributes.
This way, EF got sufficient information for generating a proper SQL statement with proper field names and schemas.
TL;DR: separate DB contexts don't handle relations (FKs) between them well, each context only has information about its own entities.
When specifying "-data-annotations" switch on dotnet ef dbcontext scaffold, these informations arent stored in each separate context, but on DB objects themselves.
