I've been working Entity Framework trying to get better with it. I'm liking what I'm seeing thus far but now have a question. With this new 'Code First' approach (from the CTP 4 download) we can now use EF from a code first approach, but I'm trying to find out if one can use an existing EDMX file with this approach.
I have a project I'm working on which has an EDMX file and I notice the ModelBuilder has a RegisterEdmx method but am not finding a lot out there on whether this will allow to use an existing EDMX file with my code first approach.
Also, I know with this new CTP things like RecreateDatabaseIfModelChanges are avilable but these options drop the database and recreate it, wont this cause all your data to be lost if you ever change your models? Is there something I'm missing here?
I can't speak to using previously generated EDMX files but there is support to use Code First with existing databases. As for the automatic Recreate, yes, this will kill all your data. This is meant only in rapid development where the persistence of data doesn't matter (and, in fact, is likely unwanted as you discover issues with business logic and want a clean start with your updates.)
This is meant only as a quick way to develop. As of (when Scott Guthrie blogged about the CTP - jump to section 5) there are no data migration features available. Your options are to manually update the database to match your model, delete the database and let it be recreated or set the automatic recreate option. Only the first option is non-destructive to your data.
Related
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
Need help! I am new to Core 2.0 and VS 2017 and haven't had much experience with MVC. I have an existing database that I need to use with a core 2.0 project at work. I was able to use the Scaffold-DbContect to initially create the domain models from the existing database.
However, the database developers are making changes to the database and adding new tables. I need to keep my domain models in sync with the database changes that are being made.
The only thing I can find on the internet is how to make changes to the model and update the database schema. However, I need to update the model from changes made to the database.
EF Core works on Code First approach. And You guys are following DB First approach together. So you should make changes in your code and then generate migrations accordingly, Otherwise, it will lead you in trouble.
You can use EF Core Power tool for generating the db changes at code side. But in this case you have to take care while generating migrations from code side.
Is there a more elegant way to maintain a view in Model-First Entity Framework? There's plenty of discussion regarding how to do this using Migrations in Code-First, but of course Migrations are not available when using Model-First.
My current approach:
Run "Generate Database from Model..."
Run the created script
Delete the table EF generates for the view
Create the view manually
The last two steps are done in a post-script, of course.
I'm not expecting an integrated view-designer (although I think that's what MS was originally intending for future releases, before they fell in love with Code-First). For example, if it's possible simply to tell EF not to create that table, it would be a small improvement.
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.
How can I do incremental developments with entity framework code first database. Because if I change something i model classes it will regenerate the database which cased to loss my data already in the database. I'm using DropCreateDatabaseIfModelChanges . Is there any thing other than that to execute alter quires rather than recreating.
EF Code First Migrations would help you here, it's in alpha/CTP currently: Entity Framework Code First Migrations: Alpha, also check out the ADO.NET team blog:
The most consistent request we have heard from you since releasing EF
4.1 has been for a migrations solution for Code First that will
incrementally evolve the database schema as you model changes over
time. Today we are announcing the release of our first Community
Technical Preview (CTP) of our Code First Migrations work.
As I recall, the Microsoft docs tell you to be sure not to use DropCreateDatabaseIfModelChanges in production environments. The point of that option is to help you come up with code-based data population for your test runs. I haven't seen any tools to help with incremental changes when using code-first. Where I work, we use a database-first setup, and we create a change script for each new release that includes alter and insert statements.
incremental database development is not currently available in the current version of the codefirst framework however it is included in the roadmap for the next release which will ship with MVC 4
as of right now you would need to remove metadata tracking from the database conventions and update the database manually via scripting or using the sql tooling until this new convention is added to the framework