Checkpoint independiente · Bloque 4 · Unidad 4.4
EX-B4-S02-04
Preservar asignaciones al crear su historial
Una base v1 contiene dos asignaciones. El siguiente schema necesita un rename, estado derivado y eventos históricos sin perder quién recibió cada activo ni cuándo volvió.
Cómo abordarla
Preserva significado al evolucionar el schema
Inténtalo desde el starter nuevo y sin copiar el ensayo anterior. La estructura y el orden del cambio son tuyos; los tests deben demostrar el contrato.
Evidencia objetivo: Sobre asignaciones v1 pobladas, diseñas rename, status, eventos y backfill desde criterios visibles, sin una revisión resuelta ni pistas.
Abrir práctica extendida: base común y 1 parte
Base común
- La revisión 0001 y cinco pruebas de continuidad empiezan verdes; 0002 está vacía y cuatro criterios empiezan rojos.
- El modelo objetivo y los criterios declaran forma e invariantes, pero no el orden de operaciones ni el código de migración.
- La base SQLite es descartable; el SQL PostgreSQL offline solo permite leer el dialecto, no sustituye una prueba de servidor.
- No se publican pistas, solución, API, contenedores, pipeline o estrategia universal sin parada.
Paquete de trabajo
- Checkpoint de historial de asignacionesAlembic v1 ejecutable y v2 vacía, datos representativos, cinco pruebas de continuidad y cuatro criterios de conservación/DDL inicialmente rojos.
Entorno, evidencia y reinicio
Entorno: Python 3.10+ en un workspace temporal; Alembic 1.18, SQLAlchemy 2, SQLite y pytest, sin servicios externos ni credenciales reales.
- Grafo, orden de operaciones y filas destino predichos antes de editar.
- Cinco pruebas de continuidad verdes y cuatro criterios inicialmente rojos.
- DDL, current y filas después de upgrade y downgrade.
Revisión: con Codex, utilizando los artefactos y criterios de cada parte; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-s02-04-assignment-history.zip y eliminar solo las bases SQLite creadas dentro de ese intento.
Parte 1 · Apoyo autónomo
EX-B4-S02-04 · Preservar asignaciones al crear su historial
Diseñar una revisión 0002 que preserve asignaciones v1, derive status, backfillee eventos y ofrezca un downgrade honesto sin una secuencia prescrita.
Qué debes hacer
- Predice el grafo, DDL, filas y orden de operaciones antes de ejecutar.
- Ejecuta continuidad y aceptación y examina metadata, v1 y la revisión vacía.
- Implementa rename, status/backfill, constraints, índice, tabla de eventos y tres eventos históricos.
- Implementa un downgrade que retire solo v2 y restaure holder_name y las dos filas v1.
- Prueba desde v1 poblada y desde vacío; documenta propietario de ejecución, recuperación y parada.
Entrega esperada
- Revisión 0002 y pruebas propias sin bases SQLite generadas.
- evidence.md con grafo, DDL, filas, current y SQL offline relevante.
- Decisión autónoma, alternativa descartada y recuperación honesta.
Criterios de aceptación
- Las cinco pruebas de continuidad permanecen verdes y los cuatro criterios nuevos pasan.
- Upgrade preserva Alicia/Bruno, deriva assigned/returned y crea tres eventos con sus fechas.
- El destino tiene checks nombrados, unique de evento, FK e índice de status.
- Downgrade restaura el schema v1 y sus valores y elimina únicamente estructuras v2.
- Una base vacía alcanza 0002 y current coincide con head.
- No se añaden API, PostgreSQL real, contenedores, CI o ramas Alembic.
Evidencia para revisión
- Predicción de rename, status, eventos, backfill y constraints.
- Baseline verde, cuatro fallos iniciales y aceptación final verde.
- Revisión actual, schema y filas verificados en ambos sentidos.
Reinicio de esta parte: Descomprimir de nuevo el checkpoint y borrar solo su base local; no copiar las revisiones de los ensayos guiados.