Actualizando las marcas de tiempo de migración en las ramas de características

Digamos que hay un desarrollo activo tanto en mi rama principal (devlop) como en mi rama de características. Ambos están agregando migraciones de vez en cuando. Antes de fusionar la rama de características en la rama principal, voy a volver a establecer una base en la rama principal.Actualizando las marcas de tiempo de migración en las ramas de características

Por lo tanto, solo tiene sentido que todas las migraciones de la rama de características se realicen después de la migración de la rama de desarrollo más reciente.

¿Existe alguna manera práctica/recomendada para hacer el cambio de nombre de estos archivos? Puedo generar migraciones ficticias y reutilizar las marcas de tiempo generadas para ellas, pero me pregunto si hay una mejor/práctica común que desconozco.

Fuente

2011-05-31 John Bachir

Solo una pregunta: ¿por qué necesita hacer esto? Rails seguirá migrándolos a todos, independientemente de la marca de tiempo. No estoy seguro acerca de las mejores prácticas, pero la práctica actual es simplemente dejarlos solos y dejarlos con sus marcas de tiempo como están. –

Haces un buen punto. es posible que una de las migraciones en la rama de características dependa de una migración en desarrollo, aunque eso no ocurrirá a menudo, ya que por definición se escribió antes de la nueva migración en desarrollo. así que tal vez la respuesta sea usar mi solución de cambio de nombre, cuando sea explícitamente necesaria. –

Lo que sucede a menudo es que las personas retroenfunden desde el enlace troncal a la rama de características para mantener la rama actualizada (para evitar fusiones horribles en sentido contrario cuando termina). Entonces, es muy posible que la rama de características dependa del código desarrollado en el tronco ... pero no al revés. –

Como se menciona en los comentarios sobre su pregunta, no es necesario cambiar los nombres de los archivos.

También se mencionó que normalmente no se producirá la migración, dependiendo de otra migración, antes de que exista otra migración. (Si lo hace, no estás haciendo las cosas bien). Entonces la necesidad no debería surgir.

En un caso raro en el que un desarrollador de funciones desearía combinar migraciones múltiples (donde hay una migración troncal entre las migraciones de características), debería fusionarlas en una nueva (o la última) migración. En cualquier caso, es responsabilidad del desarrollador de la característica asegurarse de que se cumplan las dependencias.

Hacerlo también podría crear algunos efectos secundarios molestos para otros desarrolladores. La misma migración se ejecutará nuevamente en su base de datos ya que la marca de tiempo en schema_migrations no estaría disponible.

Fuente

2011-06-01 10:38:39

Creo que decir "no estás haciendo las cosas bien" es una generalización demasiado amplia. A menudo tenemos un caso donde comenzamos a trabajar en una migración, y luego nos damos cuenta de que hay un cambio de requisito previo, por lo que tenemos que generar otra y obtenerla antes de esta. – lobati

No debería suceder que una rama de característica dependa de una migración en la rama de desarrollo, después del punto donde divergieron. Puede suceder que en la rama de características desee "anteponer" una migración, estoy de acuerdo, pero esa no era la pregunta. –

No estoy seguro de entender lo que dices. Aquí hay un caso de uso: muchas veces, cuando escribimos una rama de características, necesitaremos una migración que agregue una columna y la complete con algunos datos de otros campos y tablas. Pero en el proceso, nos damos cuenta de que los datos de origen son de alguna manera inválidos, por lo que vamos a crear una nueva rama de características para limpiar los datos y agregar algunas restricciones, fusionarlas, y luego volver a nuestra rama de características original y continuar el trabajo desde allí. ¿Estás diciendo que eso está mal? – lobati

No he encontrado una característica de rieles para hacer esto por usted, pero sería bueno tener un comando migration touch o algo así. En cualquier caso, lo que hacemos en estos días es simplemente generar una nueva migración, copiar la marca de tiempo y cambiar el nombre de la anterior. En general, las migraciones son lo suficientemente independientes como para que el orden no importe, pero ocasionalmente nos topamos con dependencias de órdenes, por lo que debemos actualizar las marcas de tiempo.

Fuente

2014-05-29 19:12:35 lobati

Heres a [gist] (https://gist.github.com/craigweston/6e64f6677b281a3d7534fb8d30152341) para el comando de migración de toque que describes. Actualiza el nombre de archivo a la última versión, llama a db: migrate: abajo en la versión anterior y db: migrate: en la nueva versión. – cweston

Actualizando las marcas de tiempo de migración en las ramas de características

Respuesta

Cuestiones relacionadas