Práctica focalizada · Bloque 4 · Unidad 4.3
EX-B4-11
Hacer atómica una transferencia con dos apuntes
Una transferencia crea cabecera y apuntes, pero confirma cada fila por separado. Si el segundo apunte viola una constraint, quedan datos parciales.
Cómo abordarla
Haz que integridad y atomicidad sean observables
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 separan conflicto unique, presupuesto de carga y operación multirow; cada uno conserva evidencia del motor, no solo del body HTTP.
Abrir laboratorio de código
1. Descarga y arranca
- Starter con commits interioresOperación multirow funcional en el camino feliz, cinco pruebas de continuidad y dos criterios rojos que exponen estado parcial y tres commits.
2. Escribe y prueba
- Predice filas sobrevivientes y commits del camino feliz antes de ejecutar.
- Reproduce el fallo de la segunda línea e inspecciona cabeceras y apuntes persistidos.
- Sustituye commits interiores por add y flush cuando necesites el id de cabecera.
- Confirma una sola vez al final, revierte ante fallo y prueba éxito y error desde una base limpia.
3. Demuestra el comportamiento
- Frontera transaccional corregida y pruebas finales.
- Tabla comparativa de filas y commits antes y después.
- Explicación de la diferencia observable entre flush, commit y rollback.
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é filas deben existir si cualquier apunte falla y para qué necesitas flush si todavía no quieres confirmar?
Todo o nada
Una transferencia válida guarda cabecera y dos apuntes con un commit; una inválida deja cero cabeceras y cero apuntes.Comprueba estas tres cosas
- ¿Cuántos commits observas hoy en el camino feliz?
- ¿Qué id puede asignar flush sin cerrar la transacción?
- ¿Quién debe decidir el commit del caso de uso completo?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista única · La frontera sigue al caso de uso
- Añade la cabecera y haz flush para obtener su id sin publicar todavía.
- Añade ambos apuntes y reserva el único commit para cuando toda la invariante pueda cumplirse.
Profundización opcional
Alinear la unidad de trabajo con el caso de uso completo usando flush para obtener claves y un único commit para publicar el cambio.
Contexto adicional
- Ejecuta continuidad y aceptación, e inspecciona la base tras el fallo intencional.
- Conserva tablas, constraints y contrato HTTP; mueve la frontera, no el dominio.
- No uses commits internos por repositorio ni conviertas la operación en éxito parcial.
Decisiones abiertas
- Puedes usar try/except explícito o un contexto transaccional equivalente, siempre que la frontera y el rollback queden verificables.
Cómo revisar tu respuesta
- Los cinco tests de continuidad y los dos criterios de atomicidad pasan.
- El camino feliz publica una cabecera y dos apuntes con exactamente un commit.
- El fallo de cualquier apunte responde con error y no deja cabecera ni apuntes persistidos.
- flush se usa solo para sincronizar y obtener claves dentro de la transacción abierta.
- La operación que conoce el caso de uso decide commit y rollback; ningún helper confirma parcialmente.
Evidencia, revisión y reinicio
- Filas sobrevivientes y número de commits previstos antes de ejecutar.
- Cinco pruebas de continuidad verdes y dos criterios de atomicidad inicialmente rojos.
- Estado persistente tras éxito y tras fallo en la segunda línea.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-11-atomic-transfer.zip y borrar solo el SQLite generado dentro de ese workspace.