Práctica · Bloque 4
Conserva datos, invariantes e historia
Sesiones, consultas, PATCH, constraints, transacciones y migraciones que preservan datos.
Starter, código, ejecución y evidencia
La actividad principal ocurre en el editor
Descarga el starter, ejecuta el baseline, modifica la API y conserva una prueba positiva y otra negativa. Las pocas actividades de análisis están marcadas de forma explícita; no cuentan como implementación.
Unidad 4.1 · Ensayo y checkpoint
Conecta modelo, sesión y contrato público
La traza distingue engine, sesión y operación; POST confirma y refresca, GET demuestra persistencia y la respuesta no filtra campos internos.
- Conectar modelo, sesión y contrato públicoUna API de activos cumple su contrato con un diccionario por instancia. El POST y el GET pasan, pero una nueva aplicación ya no encuentra el recurso.Abrir
- Hacer persistente una facturaUna API distinta evoluciona desde una factura plana hasta operaciones persistentes y una factura con líneas que debe guardarse como una sola unidad.Abrir
Antes y después de practicar
Antes: Antes de editar, clasifica qué debe vivir por proceso, por petición, por operación y más allá del proceso; después predice qué dato se perderá al recrear la app actual.
Transferencia: Ante otro recurso plano, puedes separar modelos de creación, tabla y salida, ubicar la transacción y demostrar cuándo se abre y se cierra cada sesión.
Unidad 4.2 · Ensayo y checkpoint
Conserva intención al consultar y cambiar
Los ensayos separan la matriz omitido/null/valor de la ventana SQL con filtro, orden, count, limit y offset observables.
- Reparar un PATCH que confunde ausencia con nullUna API persistente de activos admite PATCH. Enviar un body vacío responde 200, pero borra la ubicación porque el código serializa también el default no enviado.Abrir
- Construir una ventana de consulta coherenteEl listado de activos publica filtros, orden, offset y limit, pero ignora casi todos los parámetros y calcula total con len(items).Abrir
- Consultar y cambiar facturasUna API distinta evoluciona desde una factura plana hasta operaciones persistentes y una factura con líneas que debe guardarse como una sola unidad.Abrir
Antes y después de practicar
Antes: Predice dos páginas y los tres estados de un PATCH antes de ejecutar; señala qué resultado cambiaría si faltara ORDER BY o exclude_unset.
Transferencia: Ante otra colección, puedes decidir get o select, fijar un orden total, limitar la ventana y aplicar solo cambios explícitos antes del commit.
Unidad 4.3 · Ensayo y checkpoint
Haz que integridad y atomicidad sean observables
Los ensayos separan conflicto unique, presupuesto de carga y operación multirow; cada uno conserva evidencia del motor, no solo del body HTTP.
- Recuperar la sesión después de un conflicto uniqueLa base impide dos activos con el mismo tag, pero el endpoint intenta consultar con la misma Session justo después de IntegrityError y termina respondiendo 500.Abrir
- Reducir un 1+N sin cambiar la respuestaEl listado de organizaciones devuelve sus activos correctamente, pero acceder a cada colección lazy emite un SELECT adicional por organización.Abrir
- Hacer atómica una transferencia con dos apuntesUna transferencia crea cabecera y apuntes, pero confirma cada fila por separado. Si el segundo apunte viola una constraint, quedan datos parciales.Abrir
- Guardar una factura con sus líneas de forma atómicaUna API distinta evoluciona desde una factura plana hasta operaciones persistentes y una factura con líneas que debe guardarse como una sola unidad.Abrir
Antes y después de practicar
Antes: Antes de editar, predice el DDL que debe impedir el estado inválido, las filas que sobrevivirán a un fallo tras el primer commit y cuántos SELECT emitirá una colección lazy.
Transferencia: Ante otro caso de uso puedes distinguir FK de Relationship, localizar commits interiores, recuperar la Session tras IntegrityError y elegir una carga por forma de respuesta.
Unidad 4.4 · Ensayo y checkpoint
Preserva significado al evolucionar el schema
Los ensayos comparan filas antes/después, revisión actual, roundtrip y convergencia; el checkpoint transfiere el mecanismo a un historial nuevo.
- Reparar un rename que pierde datosAutogenerate representó name → display_name como add/drop. Upgrade termina y el schema parece correcto, pero dos activos pierden su nombre.Abrir
- Hacer converger un seed sin borrar datos ajenosEl seed del catálogo inserta tres categorías cada vez. Funciona sobre vacío, falla al repetirse y no corrige una etiqueta conocida obsoleta.Abrir
- Preservar asignaciones al crear su historialUna 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ó.Abrir
Antes y después de practicar
Antes: Antes de editar, separa modelo deseado, schema desplegado, datos y revisión actual; marca cada drop, rename, backfill y recuperación que el cambio necesita.
Transferencia: Ante otro cambio puedes distinguir estado de historia, revisar autogenerate, probar desde la revisión anterior y declarar un propietario único de ejecución.