I have read multiple posts about this but do not have a clear answer yet.
We are transitioning to EF Core 2.0 company-wide, one project at a time.
The challenge is this:
A new project starts and a database is created using code first, migrations etc.
another programmer needs to create a project targeting the same database.
This programmer can use Scaffold-DbContext and generate current models.
However, a new column is needed and this second programmer adds it.
Now...how do we best update the other projects?
Is there something that checks and syncs or shows what is out of sync between your model and a database? Meaning check the database for changes...not the model.
We don't mind buying a tool if that is the best solution.
The solution we have been using, very successfully is the Database project in Visual Studio.
Using that each developer has the project in their solution, changes are made against it locally.
Then we can do a "Schema Compare" inside of VS.
We have been using this successfully for 4 of us the past three weeks extensively with almost no issues.
This has even worked for keeping versions and changes to our stored procedures current.
It works well with VSTS also.
Here are some of the posts I read that helped me understand it:
https://www.sqlchick.com/entries/2016/1/10/why-you-should-use-a-ssdt-database-project-for-your-data-warehouse
https://weblogs.asp.net/gunnarpeipman/using-visual-studio-database-projects-in-real-life
..and this forum had a lot of relevant questions/answers:
https://social.msdn.microsoft.com/Forums/sqlserver/en-us/home?forum=ssdt
Related
After many fruitless searches I have decided to put my head above the parapet. I am building an EF6 code first application for an embedded device.
I have successfully followed many references to enable me to create SQL CE files in the folder locations I need.
However, I need to have two separate models running at the same time
1 - Admin model deals with common things like user logins and generic details.
2 - Project specific model where the real work gets done.
The concept is that the Admin database file resides and remains on the
device, but the project database file can be passed from one device to
another.
Is it possible to have two different model databases open at the same time in EF6?
If so is there a good reference site that my search terms have not yet found that will offer advice appropriate to my use-case?
Thanks folks.
I have been able to solve my own question now having found a new article to refer to Multiple Model EF 6 Data points
Read the article on how to solve my question and other variants of similar problems. The key to solving this problem was to specify separate folders for each context migration when commanding the NuGet Package Manager Console. Then in the initialiser for each context, refer to the configuration in the appropriate migration folder. Rather than repeating here, please see the article on MSDN I linked to as all the information I needed was in there, plus lots more.
we have a project running Entity Framework 6.1 and we started using explicit migrations a while ago (in the past we would use automatic migrations) and we have run into the following situation.
I create an explicit migration to create some indexes on fields. I do this in a seperate branch.
A colleague of mine also starts an explicit migration to do some other work in his own branch.
Each branch is code reviewed and merged into the master branch when approved.
But now we noticed that my explicit migration to create the indexes, was created on a different version of the model. Since it's a project with multiple developers, the model is always changing. So if we check what SQL code would be generated to update the database, we see that new columns/tables/... that have been added in the meantime while I was working on my branch are being dropped, that my indexes are then created and afterwards those columns would be added again.
How can we avoid this? What are we doing wrong in our workflow?
With EF 6 each migration has metadata about last state of DB.
In EFCore this is much better done with separate file that has snapshot of DB.
Here are some good practices for Migrations in Team Environments:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
How to manage Migrations in a project with multiple branches?
Now your situation is pretty specific and I am not sure that any of these procedures has automatic solution for it.
One way I can think of is to have DB model not locally but on a server and that each developer targets that when creating migration.
However in the previous blogs shared DB was not considered best practice.
You would need to figure out some hybrid procedure to comply with every advice.
Good luck...
We have recently begun using Entity Framework for accessing all the various databases we touch on a regular basis. We've established a collection of library projects, one for each of these. For many of them, we're accessing established databases that do not change, and using DB first works just great.
For some projects, though, we're developing evolving databases that are having new fields and tables added periodically. Because these libraries are used by multiple projects (at the moment, just two, but eventually many more), running a migration on the production database necessitates a republish of both/all sites that use that particular DB's library. Failure to update the library on any other site of course produces the error that the model backing the context has changed.
How can we effectively manage the deployment/update of the Code-First libraries to all of the sites that use them each time a change to the database is made?
A year later, here's what we came up with and have been using.
We now include the following line in the Application_Start() method:
Database.SetInitializer<EFLib.MyHousing.MyHousingMVCContext>(null);
This causes it not to throw a fit if the current database model doesn't exactly match what's in the code. While there is still potential for problems if non-backward-compatible changes are made, this allows for new functionality to be added without the need to re-deploy every site that uses these libraries when the affecting changes are not relevant to that particular site.
I'm looking on Entity Framework at the moment and working with Code First example. So far I can see that the framework does not handle model changes easily: whenever I want to add another field to a class/table, framework drops the entire database and creates it from the scratch.
Similar behaviour I saw in (N)Hibernate. (I could be wrong here, it was long time ago)
That is ok, as long as I work on tutorial. When a real-life project is involved, you can't afford to drop a database every time you need a new field in a table.
Just imagine scenario, you are working on a project with many clients. Every client has their own database. In release 1.0.1 I need to add a new field to one of the tables. If I drop database in my dev environment - not a big deal. (Still, I need to run a script to populate test data every time DB is dropped, and sometimes even this is no viable)
But what do I do when I need to deploy this new version? Make a SQL script to update client's databases without dropping them? then deploy binaries?
But how is this better than doing database mods separate from code changes?
(sorry for my bad english)
This is exactly why Code First Migrations exists. Take a look here (automatic migrations) and here (code-based migrations)
I have been working on a side project for the last few weeks, and built the system with EntityFramework Code first. This was very handy during development, as any changes i needed to make to the code were reflected in the DB nice and easily. But now that i want to launch the site, but continue development, i dont want to have to drop and recreate the DB every time i make a tweak to a model...
Is there a way to get EF to generate change scripts for the model change so i can deploy them myself to the production server? And how do i use the database somewhere else (Windows Service in the background of the site) without having to drop and recreate the table, and use the same model as I have already? Kind of like a "Code first, but now i have a production DB, dont break it..."
Personally i use the builtin data tools in VS2010 to do a database schema synchronization for updating production.
Another cheaper tool if you dont have VS Premium is SQLDelta which ive used in the past and is really good.
Both tools connect to the two database versions and allow you to synchronise the table schemas first. Both also have an export to SQL script functionality.
Comming up for EF is Migrations which allows you to solve just this problem within your solution however its still in beta. Migrations lets you describe upgrade and downgrade events for your database in code.
No RTM version of EF has this feature. Once you go to production you must handle it yourselves. The common way is to turn off database initializer in production and use some tool like VS Premium or RedGate Database compare to compare your production and dev database and create change SQL script.
You can also try to use EF Migrations which is exactly the tool you are asking for. The problem is it is still beta (but it should be part of EF 4.3 once completed) so it doesn't have to work in all cases and functionality / API can change in RTM.