Utilice EF Core para actualizar y modificar la base de datos de producción

Usando el código de EF Core First, en la fase de diseño, puede usar directamente Database.EnsureCreated(), EnsureDeleted()eliminar y actualizar rápidamente la estructura de datos más reciente. Como hay pocos datos, el riesgo de eliminación es muy bajo. Pero para las bases de datos que ya se han puesto en producción, este método es absolutamente inviable.

Considere el siguiente escenario:

Se lanzó el proyecto y se utilizó la base de datos de prueba local para el desarrollo. Se agregaron y modificaron muchas estructuras de tablas de la base de datos localmente. Los datos en línea son enormes y se actualizan en tiempo real. Ahora es necesario iniciar la prueba.

Si necesita actualizar la base de datos de producción, se me ocurren dos formas:

utilizar desde el principioMigration

Desde el comienzo del diseño de la base de datos, use EF Migration para garantizar que la base de datos se pueda sincronizar con el código, pero al operar, debe tener mucho cuidado, asegúrese de verificar el código de la base de datos actualizado generado y conectarse directamente a la producción. base de datos.

Cosas a tener en cuenta:

  • Úselo desde el principio Migration, nunca use declaraciones Context.Database.EnsureCreated o GuaranteeDeleted.
  • Después de su uso Add-migration, no elimine los archivos de migración generados, que registran el historial de cambios de la estructura de datos.
  • No todos los cambios se pueden reconocer automáticamente, como "modificar el caso de los nombres de las columnas de la tabla", en este caso, los datos generados en muchos casos se eliminan y luego se crean, lo que está lejos de nuestra intención original de cambiar el nombre. Así que consulte la página relacionada con migracionesBuilder.Drop en particular.

Usando andamios

Si la migración no se utiliza para la sincronización desde el principio, entonces EF Core no podrá actualizarse directamente; debemos solucionar lo siguiente:

Invertir base de datos al modelo

En primer lugar, la estructura de datos de la base de datos debe revertirse al modelo. Podemos usarlo Scaffold. Puede ver los documentos detallados aquí . Cabe señalar que en nuestro escenario, ya hay DataContext y Model modificados. Durante el proceso de andamiaje, debemos Para especificar el directorio de salida y el contexto, no entren en conflicto con el archivo actual.

Según sus propias preferencias, elija si desea utilizar -DataAnnotations o -table para especificar la tabla que se va a modificar, y la tabla no especificada permanecerá como está. De forma predeterminada, EF Core cambiará el nombre de acuerdo con sus propias reglas de nomenclatura. Si desea mantener su propia rutina, utilice el parámetro -UseDatabaseNames.

Agregar-Migración

Especifiqué el modelo de salida que se colocaría en la carpeta Modelos, la carpeta Modelos original, lo cambié a Modelos1 y cambié el espacio de nombres para garantizar que el proyecto ahora se pueda compilar normalmente.

  • Modelo exportado con DbConext: espacio de nombres Models.Models, carpeta Models
  • Nuevo modelo con DbConext: espacio de nombres de modelos, carpeta Models1,
    próxima ejecución Add-Migration.
add-migration initialcreate -context exportedContext

Esto generará una instantánea y un archivo de migración en la carpeta Migraciones. la instantánea es el seguimiento de la base de datos actual y la otra es la operación que realizará el sistema cuando utilice la actualización de la base de datos. Hay uno Up()y un Down()método, Arriba es la operación de EF en la base de datos al realizar una actualización y Abajo es revertir el cambio actual. Dado que esta es la primera vez que ejecuta add-migration, EF Core pensará que la base de datos aún está vacía, por lo que hay muchas declaraciones en ambos métodos, eliminamos todas las declaraciones relacionadas con crear y soltar. Deje el método vacío.

Migración de aplicaciones, sincronización

El trabajo preparatorio se ha realizado antes y este paso operará directamente la base de datos. Úselo update-databasepara actualizar la migración actual a la base de datos. Dado que nuestra estructura de datos actual es exactamente la misma que la de la base de datos de producción, en realidad no necesitamos realizar ninguna operación (eliminar el código dentro de Arriba y Abajo). simplemente crea modelos EF Core Link .

Entiendo que solo se trata de agregar __EFMigrationsHistoryregistros para que EF Core pueda realizar un seguimiento.

modificar el contenido del modelo

Sobrescriba los archivos en Modelos1 con los archivos en Modelos. Debido a la diferencia en los nombres de tipos, pueden aparecer algunos errores, simplemente modifíquelos según sus propios hábitos. El siguiente paso es modificar el modelo paso a paso y, a menudo, agregar migración para observar si las oraciones generadas son normales.

Desde que lo usé Identity, hay tablas correspondientes al comienzo de los datos AspNet. No uso estas tablas en este sistema (otros sistemas necesitan usarlas), así que eliminé el modelo, la instantánea y los registros DbContext correspondientes y ejecuté Add- Migración y generación Se crean los siguientes archivos:

        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.DropTable(
                name: "AspNetRoleClaim");

            migrationBuilder.DropTable(
                name: "AspNetUserClaim");

            migrationBuilder.DropTable(
                name: "AspNetUserLogin");

            migrationBuilder.DropTable(
                name: "AspNetUserRoles");

            migrationBuilder.DropTable(
                name: "AspNetUserToken");

            migrationBuilder.DropTable(
                name: "AspNetRole");

            migrationBuilder.DropTable(
                name: "AspNetUser");
        }

Significa que ahora podemos rastrear nuestras modificaciones normalmente, pero necesito mantener la tabla correspondiente aquí, así que elimine todo el contenido de arriba y abajo.

Tenga en cuenta los siguientes puntos:

actualizar el nombre del modelo

Si se usa fluentAPI, el nombre de la tabla correspondiente al modelo se especificará directamente fluentAPIen, y solo modificar el nombre del modelo no tiene ningún efecto. Si lo modifica, puede modificar la fluentAPI correspondiente o usar Anotación en su lugar.

El mensaje no puede encontrar la restricción

Para el caso de modificar la clave principal, índice, etc., si la base de datos no se establece a través de EF Core, las reglas de nomenclatura pueden ser diferentes. Para la base de datos postgresql, puede usar este nombre de consulta y luego modificar el contenido del archivo de migración correspondiente.

SELECT * FROM pg_CONSTRAINT

Limitaciones de la clave primaria compuesta

Para el caso en el que se utilizan dos o más columnas como clave primaria compuesta, EnsureCreatedel método utilizado puede reconocer Annotationla forma de la clave primaria.

[Key]
[Column(Order = 1)]
public string DeviceId { get; set; }
[Key]
[Column(Order = 2)]
public long Timestamp { get; set; }

Al utilizar Migración, este formulario no se puede reconocer y debe OnModelCreating()usarse en fluentAPI:

modelBuilder.Entity<DeviceData>().HasKey(w => new { w.DeviceId, w.Timestamp });

Se agotó el tiempo de ejecución del comando

La Commandconfiguración de tiempo de espera de ejecución predeterminada es de solo 30 segundos, lo que no es suficiente para algunas tablas más grandes. Puedes configurar:

optionsBuilder.UseNpgsql("Server=xxxxxxxxxxxxx", opt=>opt.CommandTimeout(3000));

Aumente el tiempo de espera para la ejecución del comando.

El caso de múltiples cadenas de conexión.

Si el programa utiliza appsettings.Development.jsondicho archivo para almacenar la cadena de conexión, entonces debe especificar el entorno Production(base de datos de producción); de lo contrario, es posible que se restaure en la base de datos local.
Para la consola de administración de paquetes Nuget (usando la base de datos de actualización), ejecute:

$Env:ASPNETCORE_ENVIRONMENT = "Development"
Update-Database

Para aquellos que utilizan el conjunto de herramientas dotnet ef, ejecute directamente:

dotnet ef database update --environment Development

no se puede transmitir automáticamente para escribir

Si modifica el tipo de datos de una columna al diseñar una tabla de base de datos (por ejemplo, de varchar a entero), Postgresql generará esta pregunta, lo que hará imposible la modificación. Puede migrationbuilderusar sql en y seguir las instrucciones para agregar "USING "x"::integer" para resolverlo. Sin embargo, este método todavía no es muy elegante, Up()después del procesamiento manual, es necesario procesarlo Down(), de lo contrario no se restaurará correctamente.

Esto se puede hacer mediante un enfoque paso a paso, asumiendo que necesitamos varcharcambiar el ID de a int4.

  1. Agregue un campo temporal, el tipo es int4, configúrelo en [Clave] y luego elimine el campo Id.
  2. Agregar y aplicar migración
  3. Modifique el nombre temporal a Id.
  4. Agregar y aplicar migración

Múltiples migraciones de aplicaciones

Intente hacer la menor cantidad de cambios posible cada vez, así update-databaseserá más fácil encontrar problemas. Para aquellos que tienen


Para este mensaje, asegúrese de verificar las declaraciones relacionadas con Drop en la declaración generada.

Tanto la base de datos local como la base de datos de producción tienen __EFMigrationsHistory registra las migraciones relacionadas. Al cambiar entre bases de datos locales y de producción, no hay necesidad de preocuparse por la secuencia: Update-Database aplicará la migración una por una hasta la última vez.

Resumir

El uso de Migración puede reducir una gran cantidad de carga de trabajo en la sincronización de bases de datos y puede usarse razonablemente para realizar actualizaciones en caliente en bases de datos de producción.

Nota: Este artículo pasó la prueba en .NET 6 y EF Core 6.

Expansión de contenido relacionado: (Frontera técnica)

En los últimos 10 años, cuando incluso las empresas tradicionales comenzaron a digitalizarse a gran escala, descubrimos que en el proceso de desarrollo de herramientas internas se repetían constantemente una gran cantidad de páginas, escenas, componentes, etc. La rueda hizo perder mucho tiempo a los ingenieros.

En respuesta a tales problemas, el código bajo visualiza ciertos escenarios y procesos recurrentes en componentes individuales, API e interfaces de bases de datos, evitando la creación repetida de ruedas. Productividad del programador muy mejorada.

Recomiende una plataforma de desarrollo rápido de software JNPF que los programadores deberían conocer. Este es un marco de desarrollo rápido multiplataforma simple basado en Java Boot/.Net Core. Miles de clases de uso común están encapsuladas en el front-end y back-end, lo cual es conveniente para la expansión; el generador de código está integrado para admitir la generación de código comercial de front-end y back-end, para lograr un desarrollo rápido y mejorar la eficiencia del trabajo; el marco integra formularios, informes , gráficos, pantallas grandes y otras demostraciones de uso común son fáciles de usar directamente; el marco de backend admite Vue2 y Vue3.

Experimente el sitio web oficial: https://www.jnpfsoft.com/?csdn

Si no ha comprendido la tecnología de código bajo, ¡puede experimentarla y aprenderla rápidamente!

Supongo que te gusta

Origin blog.csdn.net/Z__7Gk/article/details/132495307
Recomendado
Clasificación