You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 20, 2018. It is now read-only.
I'm really scratching my head right now, as I'm expanding upon my project. I could really use some help to get me on the straight and narrow.
What I'm building is a data aggregation platform, which has dashboards and other things that my company staff members will use. I am using Identity to determine who is using it, and all across the app I will have different unrelated subapps that may or may not need to allow user preferences/ownership to be persisted.
I'm currently modeling things with different DbContext's. For my dashboard, I have my own separate DbContext. For one of my other tools completely unrelated to the dashboard, I have a separate DbContext. It turns out though, that both need to store user preferences/data ownership and for that I am needing to utilize Identity.
It's gotten to the point now that I'm stuck, facing all sorts of errors when I'm attempting to establish relationships between the different contexts to the identity context.
I've been doing a lot of research and there seems to be a lot of favor to the idea of using a singular DbContext that handles all of these concerns... and that it's bad to attempt what I'm currently doing.
Can I get some clarification on this? For all the stuff I'm doing that will require even a minimal association with user data, should it be in the single DbContext that extends IdentityDbContext?
The text was updated successfully, but these errors were encountered:
I came across that exactly situation also several times. I ended up using one DBContext for all but it would be a really nice feature to be able to split that in several smaller module-related contexts.
I once read something about the problem sharing some entities between different contexts is, that it is possible that both contexts target different databases that can also lie on different servers.
For my projects, it also always the case, that those DBContexts target the same database, I just want some kind of modular-view on them. Maybe it is possible just to share entites like the Identity between those "local" DBContexts?
Introduce messaging . The idea is that all your "sub apps" communicate with a middle layer (web api) asking if that user has access. Then what you get in return are their claims. With those claims you can make decisions.
We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.
I'm really scratching my head right now, as I'm expanding upon my project. I could really use some help to get me on the straight and narrow.
What I'm building is a data aggregation platform, which has dashboards and other things that my company staff members will use. I am using Identity to determine who is using it, and all across the app I will have different unrelated subapps that may or may not need to allow user preferences/ownership to be persisted.
I'm currently modeling things with different DbContext's. For my dashboard, I have my own separate DbContext. For one of my other tools completely unrelated to the dashboard, I have a separate DbContext. It turns out though, that both need to store user preferences/data ownership and for that I am needing to utilize Identity.
It's gotten to the point now that I'm stuck, facing all sorts of errors when I'm attempting to establish relationships between the different contexts to the identity context.
I've been doing a lot of research and there seems to be a lot of favor to the idea of using a singular DbContext that handles all of these concerns... and that it's bad to attempt what I'm currently doing.
Can I get some clarification on this? For all the stuff I'm doing that will require even a minimal association with user data, should it be in the single DbContext that extends IdentityDbContext?
The text was updated successfully, but these errors were encountered: