Trabalhando com Entity Framework Migrations em uma base já existente
Recebi muitos feedbacks brasileiros sobre o Entity Framework Migrations e a maioria dizia que era ruim trabalhar com EF em um projeto legado por causa disso: o EF Migrations entra no projeto e ignora a base já existente. Erro pensar assim.
Quando criamos um projeto novo é mais natural trabalhar com Migrations, você pode criar o init migration e começar a cuidar do versionamento desde o início.
Se você estiver trabalhando com uma base já existente pode mapear suas tabelas utilizando o Entity Framework Power Tools e depois criar uma initial migration. Como será a primeira, os códigos da migration sugerem a criação das tabelas, por isso se você der o comando de update ele vai acusar que os objetos listados já existem. Esse é um problema, pois você não vai conseguir continuar criando migrations se tiver essa barreira, pois na tabela __MigrationHistory não vai contar que a primeira migration criada foi utilizada. Aí vai estourar na sua cara o erro:
Unable to generate an explicit migration because the following explicit migrations are pending: [201303151942575_initMigration]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
Como corrigir isso
No blog da Julie Lerman ela explica como driblar esse problema: apagar manualmente todo o método de Up e Donw da partial class gerada para essa primeira migration. Você ainda pode deixar as linhas comentadas para, sei lá, se um dia quiser ter um backup de como iniciar sua base de dados.
Porém no comando Add-Migration existe um parâmetro chamado -IgnoreChangesque adiciona uma migration ignorando o estado das classes de modelo. Esse parâmetro foi pensado justamente para se trabalhar com uma base já existente. Assim, você cria uma initial migration e o objetivo dela será só iniciar o ambiente de migrations na base de dados, criando a tabela __MigrationHistory por exemplo.
A Tabela __MigrationsHistory
A tabela __MigrationsHistory serve para manter um histórico das migrations usadas na base de dados. Ela possui somente três campos: o id da migration, o model, que é o código da migration, e a ProductVersion, que diz a versão do EF.
Se um dia você apagar essa tabela, terá problemas, por exemplo, você pode dar o comando update-database e ela será criada de novo, porém desde a primeira migration (se você não utiliza automaticMigrations).
Pode acontecer que você precise criar essa tabela na mão, por exemplo a base é muito velha, comoum Sql Server 2000. Um código de exemplo feito pela Julie Lerman é:
INSERT INTO [__MigrationHistory]
([MigrationId], [CreatedOn], [Model], [ProductVersion])
VALUES ('201202161546124_initial', '2012-02-16T15:55:56.252Z',
[big-ass hash you don’t need to see], '4.3.0')
Como vimos, é, sim, possível trabalhar com EF Migrations em base legada. Até breve