I'm using an existing database and I have mapped one of the tables as an entity (as i needed to map a foreign key).
So when it comes to initialising this database I would like EF to ignore this entity since it already exists.
How would I go about doing this?
You should create an empty migration as the first migration with the -IgnoreChanges flag to allow Entity Framework to get a snapshot of the existing database.
So out of the gate use:
Add-Migration InitialMigration -IgnoreChanges
and that will create a blank migration but it will update the Entity Framework metadata allowing the existing tables to exist and not be touched by migrations.
Also to be mentioned that the naming conventions that Entity Framework expects and your database schema may differ. You may need to manually setup the foreign keys using the Fluent API.
I didnt check with EF 6 specifically, but I think default EF behavious is that when the database exists, then it presume all model be ready and therefore will create no tables. If you want your initialization code to create tables with code first, use initialization code for prepare data. Look here :
http://www.entityframeworktutorial.net/code-first/seed-database-in-code-first.aspx
Related
I have a old DB that I need to create a new module for which will include some new tables.
The DB currently has no Entity Framework so I want to just add my new tables and just work with them and ignore the previous ones.
This post says in previous versions of entity framework you just need to do this:
add-migration Initial -IgnoreChanges
but EF Core does not support "Ignore Changes" as explained here.
I cannot find an alternative in Entity Framework Core.
How do I add my migrations for my specific tables whilst ignoring the rest of the existing database?
I have a .net core 2 project, along with Entity framework Core.
I have an existing database, and I've mapped them out to database entities in code.
The problem is that when I add a migration, expectedly it picks up my entity as a new table, however it is an existing table. The table shares the same name.
I suppose, I could just remove the contents of the Up method of the migration, but I want to know if there is a proper way instead of a workaround.
So, what I am asking is how can I tell entity framework core that this table is already existing?
EF 6 had an -IgnoreChanges option that would just take a snapshot with no Up() code, but that feature is not in EF Core (yet). See here.
If you comment out the Up() code as you have suggested that will indeed capture a snapshot of your existing objects and subsequent migrations will be incremental.
When I generated the model of the database using ADO.NET Entity Data Model, the generated model had ugly foreign keys names. I tried to change the names in SQL Server Management Studio and then I generated the model again but it did not adopt the new names of the foreign keys.
So please could anyone help me to solve this problem?
With automatic migration the name is assigned by EF.
With manual migration you can specify the name in AddForeignKey method. Here the specifications
https://msdn.microsoft.com/en-us/library/system.data.entity.migrations.dbmigration.addforeignkey(v=vs.113).aspx
EDIT
During automatic migration the EF build the name with this logic
FK_<sourceTable>_<targetTable>_<sourceFieldsList>
See EF framework source code ForeignKeyOperation.cs property DefaultName
I have changed my model and is scaffolding a new migration using the Add-Migration package manager command.
However, for some reason, EF think that I have been renaming an object for one of my classes. The class names are similar in name and have similar properties and relationships.
The problem is that the Update-Database command fails because of the rename. The very first command is RenameTable() and later on the migration tries to delete an index on the table that has been renamed (and doesn't exist anymore).
I would like to force EF to scaffold a migration where the old table is dropped and a new one is created instead. How do I achieve this? My impression was that EF can't be "smart" when figuring out renames and should always drop tables that are no longer mapped to an entity.
I'm migrating my project from database-first to code-first.
Entity Framework does some nice work creating my new database (that should mimic the old one).
I'm using a combination of data annotations and the fluent API to describe my tables.
My database has a few indexes and I would like Entity Framework to create them as well. It seems the old way to do this is to define your own Initializer and use custom T-SQL.
But now that we have EF Migrations it should be easier to do so.
I can't seem to figure out how to combine CreateDatabaseIfNotExists<> with an automatic migration to create the indexes. I've tried to use the MigrateDatabaseToLatestVersion<,> but it doesn't seem to perform the migration after the Database has been created.
What is the proper way to create indexes and constraints on database creation now that we have Entity Framework 4.3?
Don't use CreateDatabaseIfNotExists if you want to use migrations. Use MigrateDatabaseToLatestVersion from the beginning - it will create your database as well. Put your index creation code (calls to CreateIndex) into Up method of your migration class.
If you already have existing database and you want to use migrations you must first create initial migration.