The project I am working on is using Entity Framework 4.3 and data migrations to keep the schema up to date. Over the course of the project the migrations folder has grown and now has over 600 files. This is huge. We now have a binary which is over 12MB due to all the migration meta data.
I would like to collapse all these in to one migration and start again. My concerns are:
Is this possible or will it cause problems with the migration history if I remove migrations?
Are there any guides around describing how to do this?
First: I recommend that you keep your migrations in a separate assembly so they don't have to be published with the application. It could be a simple console app that applies the migrations or a winforms GUI that generates scripts. But there's no reason for it to be deployed with the app imo.
Second: Understanding that you'd be giving up the ability to roll back to previous versions, you could just exclude-from-project all of your prior migrations then generate a new one which should then be able to create a database reflecting your current model. That would serve as your new starting point. Remember that EF doesn't always generate code to do everything you want in a migration, so you might have some hand-written migration code in other migrations you'd need to pull in.
Not sure past versions, but if you are here looking for the same solution for EF Core. You should be able to just delete the ModelSnapshot and re-run your migration to create a clean sheet.
Related
I know this isn't the designed method of using EntityFramework but I have a much easier time designing the database in SQL Management Studio to create indexes, link foreign keys, etc... all visually. But I really want to use the automatic database updates for the future when deploying updates to customers.
I designed the original database in SQL Management Studio then created the EntityFramework code first from that database. But if I want to add another table so far, I end up dropping everything then regenerating the DB from SQL Management Studio. This has been ok for the first part of my framework development but now things are starting to get a little more complex.
I've tried to learn the code first mechanism but some of the more complex items have bit me and I don't have a lot of time to allot for this. I was hoping there was a hybrid way of designing in SQL Management Studio then utilizing the database deployment functionality built into EntityFramework.
I'm working on getting the POCO reverse generator running here but having some issues. Ultimately, I think that is the way I'll want to go. But I did find a temporary workaround with existing tools built into VS2019 until I get that tool working.
I made a copy of the name of the model because I had a custom initializing for the connection string.
Delete the model file
I right clicked the folder where the codefirst files are placed in my solution then add-new item
Select ADO.NET Entity Data Model and named id the same as the one in step 1
Select Code First from Database
Deselect saving connection string (it won't overwrite and the needed one is already in the app.config)
Select the tables to import
In my case I deselected the Pluralize object names
Finish
Update the master model file with the custom initializer
In the package manager console enter: add-migration (I'm assuming you already have migrations set up)
name the migration
add-migration [name in step 12] (this applies the migration)
It might seem like a lot of steps, but it's actually not. And so far with a couple of days of playing around with it, I'm not running into any issues.
I'm trying to upgrade my app to ASP.NET Core 2, with EF Core 2 (and SQLite), in other words netcoreapp2.0. I followed the upgrade guide.
I also recreated migrations, and noticed the new ones are quite different from the ones I remember from 1.1 (different commands sent to the db, different syntax, etc). But my model is the same, and after generating migrations, everything compiles properly.
BUT, when I try to create the db programmatically using context.Database.Migrate();, or manually on the CLI using dotnet ef database update, I get
System.NotSupportedException: SQLite does not support this migration operation ('AddForeignKeyOperation'). For more information, see http://go.microsoft.com/fwlink/?LinkId=723262.
However, I don't use the AddForeignKeyOperation command anywhere in my solution (I searched for it). I searched my migration files, and they don't use that command.
I'm sure it's something basic, but I can't track it down. What could it be?
Turns out the problem was not deleting all migrations.
I had the "initial" migration, then migration1, migration2, etc. The initial migration is from the template, so it had Identity/roles/users/etc. So I left that one alone and deleted/recreated the other ones only (i.e. the ones with my domain model).
Well it turns out that when I deleted ALL migrations, and recreated them, I stopped getting that error.
That error is confusing and poorly worded, and has nothing to do with the problem. Hope this helps someone else.
I just started using EF 6 and I noticed that the first execution takes more time because it needs to be compiled, so I researched and found that you can pre-generate the view.
I used EF Power Tool to generate the view: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
It's a dll, and I'm building using the option Embed in Output Assembly.
The problem is that even though I have the view.cs when I execute the first query I have the same delay, so it seems that my library is not using the pre-generated view.
What could be wrong? I'm passing the connection to the entity using an EntityConnectionStringBuilder returning a EntityConnection object.
Also I tried changing the view.cs to Embedded Resource, since with Compile I did not have any changes, in both ways I still have the first time delay.
I'm sure I'm missing something, but not sure what.
Thanks in advance,
Lucas.
EF5 views will not work with EF6 (in addition to that there are some issues with EF6 Beta 1 and EF6 RC1 which prevent using views with EF6 - these issues should be fixed for EF6 RTM). I created a T4 template for generating views for EF6 - you can find more details here - again due to the problems above the views generated by the template will not work for EF6 RC1. If you absolutely think you need it you can try the version from my github - it was updated to work with EF6 RTM and also works with nightly builds.
Anyways, I am pretty sure that this is actually not view generation that are causing the issues (actually the performance of view generation in EF6 has been greatly improved). We recently found a few performance issues (see 1674 and 1662) that are affecting start up time and we are looking at these.
EDIT
The version of the template that works with EF6 RTM (6.0.0.0, 6.0.1.0) has been published to the VS Gallery
I've been using EF 4.1 and the POCO template generator.
I love and hate EF. I love the time I save. I hate maintaining the EDMX file.
But while keeping the EDMX in sync with the database has been a challenge, I'm now overwhelmed by the POCO generator. Up until now, the POCO generator has created POCO's for me and kept the ClassObjects.Context.cs empty and non-conflicting.
After my most recent refresh I have had constant problems with "Amiguity between 'perseus.DataLayer.accounts' and 'perseus.DataLayer.accounts'.
I get this error for every POCO.
I'm on the edge of panicking as I recommended and owned the maintenance of EF. I've spent a couple days on trying everything from database refreshes to deleting all items from the EDMX file and reloading them from the database.
Nothing has made a difference. I have no clue what has suddenly changed from the last few months of relative stability. I'm seriously lost as to what I can do from here.
It looks to me like you have not disabled the code generation strategy. click on the designer background and check the properties tab, the first item is Code Generation Strategy. This should say None, and not Default.
Editing the edmx manually is difficult and error prone. I would suggest copying what you have off to another location then letting the tool regenerate the edmx for you. Compare the two.
I worked with some DB2 entities that I had to manually sync and had constant issues. The tool would clobber my changes and I would have to manually replace that with working code.
If at all possible, don't modify the edmx code yourself. If you must, make the changes, copy those off to a text file in the project for tracking/safe keeping.
I am using Code First Data Migrations and have my development database so built up that I really don't want to start fresh again. I had deleted an old table and cannot get EF to accept any model changes due to this lingering phantom table. How can I get a clean version of my database context based on the model that's currently in place? Any help would be greatly appreciated!
You could use a "Code Second" approach and reverse engineer the model from the database. A good way to do this is to use the Entity Framework Power Tools for VS to do the reverse engineering. Once it is installed just right-click the project and select Entity Framework > Reverse Engineer Code First and select the relevant database in the dialog. This will generate a model in the Model folder.
I usually do this in a dummy project and then copy the files across. The model generation is actually very clean and adds some nice features like initializing ICollections to a new List in the constructor which are sometimes left out of the original Code First model.
EDIT
Here is an article which outlines the process using EF with an Existing Database