entity framework - relaciones - Migración no deseada para el objeto asignado a una vista

migraciones.net core

Question

El problema

Tenemos un objeto

public class Foo
{
    [Key, Column(Order = 0)]public virtual int A { get; set; }
    [Key, Column(Order = 1)]public virtual int B { get; set; }
}

eso necesita ser mapeado a una vista indexada en SQL Server. Construyendo sobre los enfoques

Primer código EF: Asignación de objetos no tables con Fluent API y https://stackoverflow.com/a/20887064/141172

primero creamos una migración inicial

public override void Up()
{
    CreateTable("dbo.Foos",
        c => new { A = c.Int(nullable:false), B = c.Int(nullable:false) })
        .PrimaryKey(t => new { t.A, t.B });
}

Luego, una migración vacía en la que agregamos SQL para colocar la tabla generada automáticamente y luego agregar el índice

public override void Up()
{
    Sql(@"DROP TABLE Foos");
    Sql(@"CREATE VIEW dbo.Foos As....");
}

finalmente en nuestro DbContext, Foo está mapeado a la vista:

modelBuilder.Entity<Foo>().ToTable("Foos");

Esto funcionó bien, hasta que agregamos otra propiedad a Foo:

[Key, Column(Order = 2)]public int C { get; set; }

Agregamos una nueva migración para redefinir la vista

public override void Up()
{
    Sql(@"ALTER VIEW Foos ....");
}

La migración de Alter View se aplica correctamente, pero EF cree que debe crear una migración para tener en cuenta la nueva propiedad.

No se puede actualizar la base de datos para que coincida con el modelo actual porque hay cambios pendientes y la migración automática está deshabilitada. Escriba los cambios del modelo pendientes en una migración basada en código o habilite la migración automática.

Cuando corro

Add-Migration WhatIsPending

EF genera

public override void Up()
{
    DropPrimaryKey("dbo.Foos");
    AddColumn("dbo.Foos", "C", c => c.Int(nullable: false));
    AddPrimaryKey("dbo.Foos", new[] {"A", "B", "C" });
}

Pregunta

¿Hay un mejor enfoque para asignar un objeto a una vista, de modo que los cambios en el objeto sean indoloros?

Si este es el mejor enfoque, ¿cómo puedo informarle a EF Migrations que no necesita generar la migración?

Answer 1

No pudimos encontrar una manera de decirle a EF que no cree una migración, pero este enfoque podría ayudar:

1. Cuando crea POCO, no CreateTable() en la migración. si EF quiere crear un archivo de migración, está bien, pero puede comentar el código para que solo su Sql(@"Create View ..."); carreras.

2. Todo lo que teníamos que hacer entonces era crear el DbSet para la vista, no una entrada modelBuilder.Entity .

3. Cuando necesite hacer cambios, comience de la misma manera que cualquier otra tabla. Realice cambios en POCO, luego ejecute Add-Migration y permita que cree la migración por usted. comente lo que quiera hacer y agregue su secuencia de comandos Alter View . Asegúrese de hacer una correspondiente en el Down .

De esta forma, solo tendrá un único archivo de migración para cada cambio.