ASP.NET core, Access Table that is defined in another project
I have defined and created a table ("Files") in another project than the project i wanna access the data from, is that even possible? Cuz I cant do _context.Files, bec the context doesent have Files bec its defined in another context in another project.
12 Replies
To clarify im using the same sql db for two projects, my web app project (where I wanna get the File from the table FIles) and my azure functions project (where I have the Files in the context and where I set the File)
its defined in another context in another project.Since entity configurations are also per-context, that means EF wont be able to generate appropriate sql queries, unless those configurations are also added to "this" context. You dont need a
DbSet<T> in your context thou, you can just use context.Set<T> instead, but all the caveats above apply: the type must exist, it needs to be either entirely unconfigured or have the configuration loaded in both contextsis it possible to access the data?
what do u mean with configuration loaded in both contexts? I tried adding DbSet FIles to this context as well but it said there already was an table named Files in db
if its the same actual database, and the same type (or a matching type) with the same configuration
yeah thats the problem you're gonna get, it will try to generate migrations for that table
yes its the same db
it should however technically work, if you somehow avoid the migration problem
manually editing the snapshot file to add the other table, for example 😄
this is going to be a nightmare to maintain, fyi
thanks, okay, wierd that I cant find any simple solution for just accessing data from the db
thats not at all what you asked thou
you can execute raw sql with EF Core, or you could go down a step and use SqlConnection and maybe Dapper
ok
EF is an opinionated library that expects you to follow a lot of conventions, when you break those conventions (like accessing a type that is "owned" by a different context), you get pain.
its probably easier to bypass EF if this is a one-off thing
okay thanks
dapper