Closed danjohnso closed 2 years ago
@danjohnso Can you post a runnable project/solution or complete code listing that demonstrates the behavior you are seeing.
@ajcvickers Guess not. Tried the same scenario in a new test project but the migration seems to work ok. Not sure how I can extract this to something reproducible since it is a project that has been around a while ...any way I can track where it is picking up this reference in the model? Verbose mode on the migration generation doesnm't provide anything useful. Its probably 20 different tables we removed from the BaseContext and commenting them out individually just opens up for the next one in line to cause an issue so its not isolated to a single entity.
@danjohnso My best guess is that there is a reference to the type somewhere in the model so it is still being pulled in. For example, a navigation property that points to the type. If it's something else, then I don't have any ideas as to what that might be.
@ajcvickers Spent a couple hours looking for navigation properties and possible indirect references and I couldn't find anything. I have my actual context setup pulled out of the main application and the issue still happens when trying to add the migration on an empty ConsoleApp. Do you have a way I can share without posting it publicly?
@danjohnso You can email it to me. At "microsoft.com", I am "avickers".
Sent the repro Wednesday night, let me know if you need anything else. Spent some more time looking at dependencies and still haven't found anything that would indicate there is a reference to those classes in the TenantBContext
@danjohnso Got the repro, thanks. I haven't had time to look at it yet.
@danjohnso One connection is coming from Task
which is mapped with both it's sub-types here:
entity.HasDiscriminator<int>("Discriminator")
.HasValue<P****.Task>(1)
.HasValue<G***.Task>(2);
This is one way that the reference to both tenants gets included in the model, which then results in further dependencies coming in, which ultimately brings in BasicMaterialDefinitionMasterModelCustomerInformation
. I stopped here, so there may also be other references.
Thanks for clarifying the behavior, didn't think using TPH would trigger it being included in the base model...guess I will need to wait for TPC to split these databases up.
EDIT: In case anyone else comes across this in search with a similar scenario, I did find I can force remove the objects from the model by specifying which objects I didn't want in OnModelCreating of the derived context. Little bit of a pain, but this keeps the tables out of the database from what feels like an implicit reference.
modelBuilder.Ignore<BasicMaterialDefinitionMasterModelCustomerInformation>();
public abstract class BaseContext : DbContext {} public class TenantAContext : BaseContext {} public class TenantBContext : BaseContext {}
BaseContext currently has an object called BasicMaterialDefinitionMasterModelCustomerInformation. TenantBContext no longer needs that table, so I removed the DbSet from BaseContext and moved it to TenantAContext. Adding a migration for TenantAContext worked fine. When I went to add a migration for TenantBContext, I get the exception below. TenantBContext has no references to that object anymore, but any attempt to do migration work or instantiate the context causes an exception like below on the IModel. I am assuming something is cached in the ModelValidator from when TenantBContext did have a reference via the BaseContext, but I am not sure how to work around this...feels like a bug but wanted to see if there was a workaround in the meantime.
Further technical details
EF Core version: 2.1.3 Database Provider: Microsoft.EntityFrameworkCore.SqlServer Operating system: Windows 10 IDE: Visual Studio 2017 15.8.5