Pregunta

Tengo dos máquinas ... una máquina de desarrollo y una máquina de producción. La primera vez que introduje mi aplicación Rails en el servidor de producción, no tuve ningún problema. Simplemente importé schema.rb ejecutando rake db: schema: load RAILS_ENV = production. Todo estaba bien.

Entonces, en mi máquina de desarrollo, hice algunos cambios más y otra migración, y luego copié la nueva aplicación en la máquina de producción. Luego intenté actualizar la base de datos ejecutando rake db: migrate RAILS_ENV = production. Obtuve el siguiente error: " Ya hay un objeto llamado 'schema_migrations' en la base de datos. "

Estoy pensando en mí mismo, no es broma Rake ... ¡lo creaste! Hice un seguimiento del rastrillo y parece que el rastrillo piensa que es la primera vez que se ejecuta. Sin embargo, al analizar mi tabla 'schema_migrations' en mi máquina de desarrollo y en mi máquina de producción, puede ver que hay una diferencia de una migración, es decir, la que quiero migrar.

También intenté definir explícitamente el número de versión, pero eso tampoco funciona.

¿Alguna idea sobre cómo puedo actualizar mi servidor de producción?

Update:

Permítanme comenzar diciendo que no puedo "soltar" la base de datos. Es un servidor de producción con un poco más de 100k registros ya en él. ¿Qué sucede si ocurre un problema similar en el futuro? ¿Debo abandonar la tabla cada vez que se produce un problema en la base de datos? Puede funcionar esta vez, pero no parece ser una solución práctica a largo plazo para todos los problemas de la base de datos. Dudo que el problema que tengo ahora sea único para mí.

  1. Parece que la tabla 'schema_info' y la tabla 'schema_migrations' son las mismas. En mi configuración, solo tengo 'schema_migrations'. Como se dijo anteriormente, la diferencia entre la tabla 'schema_migrations' en el servidor de producción y la máquina de desarrollo es solo un registro. Es decir, el registro que contiene el número de versión del cambio que deseo migrar.

  2. Del libro que leí, 'Simply Rails 2', dice que cuando se muda por primera vez a un servidor de producción, en lugar de ejecutar rake db: migrate, uno debería ejecutar rake: db: schema: load.

  3. Si importa, estoy usando la versión 2.1 de Rails.

No hay solución correcta

Otros consejos

Esto es una suposición, lo admito: creo que debido a que primero ejecutó db: schema: load en lugar de db: migrate en su entorno de producción, obtuvo la estructura de su db, pero no los datos que migran se pueblan en su tabla schema_info. Entonces, cuando ejecuta migrate en el entorno de producción, no hay datos en schema_info, por lo que migrate cree que aún no se ha ejecutado (porque no lo ha hecho).

Dicho esto ... dices que has buscado en " schema_migrations " tabla, y que hay una diferencia de una versión de desarrollo a producción ... No he oído hablar de esa tabla, aunque tengo unos meses de retraso en mi versión de rieles. Tal vez podría intentar crear un " schema_info " tabla en el entorno de producción, con una única '' versión '' y agregue una fila con la versión en la que cree que se encuentra su entorno de producción.

Si obtienes " Ya hay un objeto llamado 'schema_migrations' en la base de datos. " ¿Mensaje de error entonces sospecho que está utilizando MS SQLServer como su base de datos? (Como parece un mensaje de error de MS SQL Server)

En caso afirmativo, ¿qué adaptador de base de datos ActiveRecord está utilizando? (¿Cuál es su archivo database.yml, qué gemas ha instalado para acceder a la base de datos de MS SQL Server?)

Actualmente parece que Rails no encuentra la tabla schema_migrations en el esquema de producción y, por lo tanto, intenta crearla y esta creación falla con el mensaje de error de la base de datos. Probablemente, la razón son los caracteres en mayúscula / minúscula en el nombre de la tabla de schema_migrations, por lo que entiendo, los identificadores de MS SQL Server distinguen entre mayúsculas y minúsculas.

Dependiendo del sistema utilizado en la producción, he visto casos en que lo siguiente no funciona:

rake db:migrate RAILS_ENV=production

Pero donde este funciona:

RAILS_ENV=production rake db:migrate

Extravagante, lo sé, pero vale la pena intentarlo para ver si hace la diferencia.

Respecto a tu actualización:

  1. No entiendo cuál es la diferencia entre su schema_migrations de producción y la versión dev. ¿Hay un registro en ambas tablas (debería haber solo 1 columna, " versión " ;, derecha) o hay un solo registro en la base de datos dev y cero registros en producción? Si hay cero registros en la tabla de producción, haga esto:

    ActiveRecord :: Base.connection.execute (" INSERT schema_migrations (version) VALUES (# {mi número de versión que la producción supuestamente está en}) "))

  2. Alternativamente, puede intentar soltar la tabla schema_migrations totalmente en producción:

    ActiveRecord :: Base.connection.execute (" DROP TABLE schema_migrations ")

    Luego, vuelva a ejecutar rake db: migrate RAILS_ENV = production . Sin embargo, eso ejecutará las migraciones desde la versión 1, que probablemente no sea lo que buscas.

  3. Alternativamente, como alternativa, puede iniciar una sesión de IRB en su entorno de producción, ya sea "requerir". o "cargar" (Nunca puedo recordar cuál, o si es importante) del archivo de migración que desea cargar, y luego llamar a MyMigrationClass.up . Después de eso, tendría que establecer manualmente el número de versión en la tabla schema_migrations, ya que aún así tendría un problema, pero como un tipo de hack de solución rápida, funcionaría.

Simplemente soltaría el DB, lo agregaría de nuevo y ejecutaría rake rb: migrate. Brad tiene razón al decir que cuando ejecutó la carga del esquema, no colocó ningún registro en la tabla schema_migrations.

Esto es más complicado, por supuesto, si hay datos que no puede perder en el servidor de producción. Puede obtener las tareas de copia de seguridad de rake (no estoy seguro de si es parte de Core o no) y luego ejecutar rake db: backup: escriba en su base de datos de producción, y luego, una vez que haya actualizado las migraciones de producción, ejecute rake db: copia de seguridad: leer.

schema_info es de una versión anterior de Rails. schema_migrations es el nuevo chico en el bloque. Debería poder eliminar la tabla schema_info ya que ya no se usará. Probablemente querrá buscar cualquier problema asociado con este cambio de nombre.

rake db: schema: load cargará la estructura de la base de datos desde schema.rb. Este archivo es la representación actual de la estructura de la base de datos. Se utiliza cuando tiene un esquema (base de datos) vacío que necesita la creación de todas las tablas e índices. Le ahorra tener que ejecutar todas las migraciones. Si tiene una base de datos de producción existente con datos, no desea ejecutarla. Como han dicho otros, ¡eso sería malo!

Sé que este post fue hace algún tiempo, pero lo encontré y realmente no ha sido respondido. A medida que aparece en google, aquí va.

Cuando hiciste un rake db: schema: dump (o cuando esto fue hecho por ti por los scripts de compilación) habrá puesto la definición de la tabla de migraciones en schema.rb. Al final de la secuencia de comandos, el proceso intentará crear la tabla nuevamente, sin embargo, obviamente ya existe. Simplemente elimine la tabla de migraciones de schema.rb antes de ejecutar rake: schema: load y no habrá ningún mensaje de error.

Deberá configurar el número de versión en la tabla de migraciones para ejecutar migraciones posteriormente. Por lo tanto, es importante saber a qué versión se refiere también su schema.rb, o eliminar todas las migraciones antiguas (¿están en su SCM de manera segura?)

rake db:migrate RAILS_ENV=production

Use la tarea db: schema: load solo para la primera creación, los cambios incrementales deben migrarse.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top