Práctica focalizada · Bloque 4 · Unidad 4.4
EX-B4-13
Reparar un rename que pierde datos
Autogenerate representó name → display_name como add/drop. Upgrade termina y el schema parece correcto, pero dos activos pierden su nombre.
Cómo abordarla
Preserva significado al evolucionar el schema
Ejecuta primero el baseline. Después modifica la frontera indicada, escribe una regresión positiva y otra negativa y conserva la salida real.
Evidencia objetivo: Los ensayos comparan filas antes/después, revisión actual, roundtrip y convergencia; el checkpoint transfiere el mecanismo a un historial nuevo.
Abrir laboratorio de código
1. Descarga y arranca
- Starter de rename destructivoEntorno Alembic real con dos revisiones, candidato drop/add, cinco comprobaciones baseline y dos criterios de conservación rojos.
2. Escribe y prueba
- Registra history, current, DDL y filas en 0001 antes de aplicar el candidato.
- Aplica head, identifica qué operación perdió valores y compara la intención con el diff.
- Sustituye drop/add por un rename reversible compatible con el entorno descartable.
- Ejecuta upgrade y downgrade desde una base v1 nueva y documenta el límite de recuperación.
3. Demuestra el comportamiento
- Revisión 0002 corregida y pruebas finales.
- Tabla de revisión, columnas y valores para cada estado.
- evidence.md con intención, riesgo, alternativa y condición de parada.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
¿Qué evidencia distingue un rename de una eliminación y por qué el modelo final no puede responderla?
Roundtrip con significado
Router Madrid y Laptop Norte sobreviven a 0001 → head y head → 0001 con los nombres de columna esperados.Comprueba estas tres cosas
- ¿Qué revisión registra la base antes del cambio?
- ¿Qué valores sobreviven al candidato actual?
- ¿El downgrade restaura datos o solo una columna vacía?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Revisa la intención
- El par add/drop produce la forma final, pero no mueve el valor.
- Busca una operación que cambie el nombre de la columna existente.
Pista 2 · Prueba ambos sentidos
- Parte siempre de 0001 con filas nuevas.
- El downgrade honesto invierte el rename, no crea una columna vacía.
Profundización opcional
Tratar la revisión como un candidato, recuperar la intención de rename y demostrar conservación de valores en ambos sentidos sobre una base v1 poblada.
Contexto adicional
- Ejecuta baseline y aceptación y conserva la salida inicial.
- Modifica únicamente la revisión 0002; no reescribas 0001 ni los fixtures.
- Verifica schema, revisión y filas; un exit code cero no cierra la actividad.
Decisiones abiertas
- Puedes usar alter_column o batch_alter_table; justifica la opción desde el dialecto y la prueba, no desde preferencia estética.
Cómo revisar tu respuesta
- Las cinco pruebas baseline y los dos criterios de roundtrip pasan.
- Upgrade conserva ambos nombres bajo display_name y registra 0002.
- Downgrade restaura name con los mismos valores y registra 0001.
- 0001 no se reescribe y no se usa create_all como sustituto de la revisión.
- La evidencia explica por qué autogenerate no podía inferir la intención.
Evidencia, revisión y reinicio
- History/current y filas v1 registrados antes del cambio.
- Cinco pruebas baseline verdes y dos criterios de roundtrip inicialmente rojos.
- Columnas y valores observados después de upgrade y downgrade.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-13-rename-review.zip y eliminar solo las bases SQLite creadas dentro de ese intento.