Hey, I'm desisingn an application module that depends on our core module entities. In the application module, I have entites that reference core module entities via Id reference. I'm trying create a solution where it would be easy and efficient to join data from core module entites to a query in the application module. The module is designed to be an integrated part of the system so dublicating data into that module is not the best solution. The entity extension system doesn't seem to be quite what I'm looking for either.
One way to achive this would be to use DbContext inheritance so the core module entites would be in use through the application module dbContext. However this is not possible at the moment because I ran into this problem: https://stackoverflow.com/questions/41829229/how-do-i-implement-dbcontext-inheritance-for-multiple-databases-in-ef7-net-co . The suggested solution would be to add the protected constructor with non generic options injected as parameter. This would have to be in the AbpDbContext however.
I'm wondering would be the suggested way to link dbContexts together or join data over multiple dbContexts?
7 Answer(s)
-
0
It is something like "How to join tables in a microservice system where each service has its own database".
Problem is similar because we've designed each module so that they can be deployed as a independent microservice if needed.
Isn't there any solution?
Performing a join assumes that both module tables will always be in the same database. With this assumption;
- You have two modules: A & B.
- A has entities like A1, A2, A3... and B has entities like B1, B2, B3.
- You want to Join with A1 & B2 entities inside the A module's source code.
Problem: That's not possible because they are in different DbContexts. Solution:
- Create a similar entity (AB2) to B2 in the A module (you can directly copy or create a similar entitiy with the only properties required for module A).
- Map this entity (AB2) to the same database table with B2.
- To not have problem in your migration, don't include this mapping in the unified migration.
You can find more information about the implementation here
If this answer does not help or is not sufficient to solve your question, please reply to me.
-
0
Thank you for your answer! Can you please clarify what this means "To not have problem in your migration, don't include this mapping in the unified migration." If I create the "dublicate" entity into module A. I have to have entity configuration to map the entity into the same table. How would I then exclude the configuration from migration creation?
-
0
A similar approach can be found in the ABP Commercial project template. See the
*.EntityFrameworkCore.DbMigrationsprojectpublic class MyProjectMigrationsDbContext : AbpDbContext<MyProjectMigrationsDbContext> { } -
0
Can you please clarify what this means "To not have problem in your migration, don't include this mapping in the unified migration." If I create the "dublicate" entity into module A. I have to have entity configuration to map the entity into the same table. How would I then exclude the configuration from migration creation?
Actually, if you have done "Map this entity (AB2) to the same database table with B2" correctly, you should not have any problems.
Because it was already created by module B in that entity database. When you create a new entity with the same name in module A and configure it similarly, you will see that it is not included in the unified migration.
If it is included in the unified migration, there may be two different tables in your database doing the same job, in this case it is useful to check as it is not wanted.
You can also look here for an example.
-
0
Ok, thank you. I get the impression that you would not prefer DbContext inheritance in any case. What problems do you see in that approach?
-
0
As with anything, it's a tradeoff. You can find why in the "Motivation" section of this article.
-
0
This question has been automatically marked as stale because it has not had recent activity.
