Mapping single model to multiple databases
Like to be able to build a domain model over data in multiple databases. With out having to manage database objects - linked servers, views etc.
Add to the [Table] attribute the DataBase parameter that could map the table to a different database.
Reverting status from “under review” to “no status” since we aren’t currently working on this. We will still consider it for future releases.
Now "No Status"? Why don't you add some developers to EF development and make it a first class framework? There are LOTS of missing pieces! Listen to your customers and then staff for the requests please!
Really? Under review for 3 years while we all suffer?
Todd Aspeotis commented
I don't deal with large applications all that often and I've just come across two where one has to read data from the other's. It doesn't make sense to put the two databases together, or to have some n-tier solution where web services are called and entities are cached etc. Direct access to the database gives us best performance and is reasonably maintainable.
Right now we're using views and synonyms to surface parts of the first database into the second. It's not a huge burden, but less elegant than, say, EF understanding multiple database and being able to query across them.
Mojtaba Kaviani commented
This is important for large scale software developing. can shared data to one database and each other software have self databases.now in software can access shared and self data.
Michael Snead commented
LINQ to SQL DBML's can do this by changing the schema of a given table.
How is it that EF has NO WAY built in to do this? :( EF is the future - this needs to be fixed!
Does anyone have any comments on this option?
Nico Sap commented
I'm changing the ConnectionString within EF and it just works.
I use +/- 50 difference databases after the users login by overriding the connectionstring in DataContext.
When using migrations, you can adjust the connectionstring (Update-Database ...), so this also works.
This shouldn't be a primairy task, it isn't that hard to change it all.
This is very much required when the application supports multi-tenancy. And today, everybody wants to develop multi-tenant app....
R Kevin Burton commented
Need to support either multiple databases in a single context or multiple contexts in a single query.
This isn't a wish or a want... IT'S ESSENTIAL. @Ladislav: while I respect you, sometimes you can't see past the end of your nose... no fuss Cross database and Cross server querying is totally within the realm of the ORM - the whole point of it is to isolate you from the physical persistance store - for example, just look at what Azure does for servers (makes them disappear into a single entity is the answer in case you're struggling)
Why was this feature not added from the get go? I think this was a huge blunder. Because it added dozens of hours of coding in my team to achieve what EF cannot do right now. so our decision was to not use EF at all for this project and build our own EF to support multiple DBs. This is costing me money.
People this is extremely important, imagine an ERP system?
Misztur, Chris commented
Openquery over linked servers would be awesome! Thanks for EF thus far.
The sooner the better
Miroslav Kovacevic commented
We need this for yestarday.
Yes, we need this for larger applications.
This is extremly required for enterprise projects. We need to use multiple db on the single mssql server.
Please add this feature as soon as possible you can.
This is required for enterprise project development. We are currently using multiple db's with MS SQL on single db server. We are also using synonym and merging edmx files.as a work-around. Please add this feature.
A direct mapping of synonyms is required. One of Entity Framework's claims is that it works best with Microsoft SQL Server, so this is expected. Although there are ways of merging edmx files together that's not a direct approach which we expect to have when using the Entity Framework
Arkadiusz Kaminski commented
It'd be great if this feature was implemented in EF. I'd reduce lots of hassle with creating views / store procedures to bypass that limitation.
On the other hand: while developing multi database enterprise solutions you may look into the SOA approach.