Práctica focalizada · Bloque 4 · Unidad 4.1
EX-B4-02
Conectar modelo, sesión y contrato público
Una 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.
Cómo abordarla
Conecta modelo, sesión y contrato público
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: La traza distingue engine, sesión y operación; POST confirma y refresca, GET demuestra persistencia y la respuesta no filtra campos internos.
Abrir laboratorio de código
1. Descarga y arranca
- Starter de activos efímerosAPI en memoria, cinco tests de contrato verdes, dos criterios ejecutables inicialmente rojos y plantilla de evidencia; sin SQLModel ni solución.
2. Escribe y prueba
- Registra el baseline y clasifica engine, Session, transacción y fila por ciclo de vida antes de editar.
- Define modelos distintos de creación, tabla y salida; deja table=True solo en el modelo persistente.
- Crea un engine estable para la app, registra metadata antes del bootstrap local y proporciona una Session nueva mediante yield.
- Reemplaza el POST por model_validate, add, commit y refresh; adapta el GET solo lo necesario para demostrar lectura por id.
- Añade una prueba o traza de apertura/cierre por petición y ejecuta baseline y aceptación hasta dejarlos verdes.
3. Demuestra el comportamiento
- Código persistente y tests propios, sin incluir una base generada.
- evidence.md con predicción, comandos, ciclos observados y límite de parada.
- Salida de ambas suites e inspección breve de tabla, fila y contrato OpenAPI.
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é objeto debe vivir por aplicación, cuál por petición, dónde se confirma la escritura y qué prueba demuestra una fila en lugar de otro diccionario?
Frontera de supervivencia
La misma ruta de SQLite se entrega a dos llamadas de create_app. La primera crea el activo; la segunda debe recuperarlo sin recibir el diccionario anterior.Comprueba estas tres cosas
- ¿Qué resultado esperas al crear dos apps sobre la misma ruta de archivo?
- ¿Qué campos pertenecen a AssetCreate, AssetTable y AssetPublic?
- ¿Qué observación distingue commit, refresh y close?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Empieza por los tres contratos
- Solo el modelo de tabla registra metadata y puede tener un id todavía ausente.
- El modelo público debe exigir el id y omitir internal_note.
Pista 2 · Separa lifecycle de decisión
- El `with Session(engine)` rodea a yield y garantiza close.
- La operación que conoce la escritura ejecuta add, commit y refresh en ese orden observable.
Pista 3 · Prueba otra instancia
- Construye dos apps con el mismo `tmp_path / assets.db`.
- No pases el diccionario ni el objeto creado de una instancia a la otra; pasa solo el id público.
Profundización opcional
Reemplazar el estado efímero por SQLite y completar una creación con modelos separados, engine estable y Session por petición sin alterar la representación pública.
Contexto adicional
- Ejecuta primero `pytest`: los tests de contrato suministrados deben estar verdes.
- Ejecuta después `pytest tests/acceptance`: sus dos fallos iniciales son visibles y describen la propiedad pendiente.
- Conserva método, path, status, body, 404 y OpenAPI; no añadas listados, PATCH, relaciones ni capas obligatorias.
Decisiones abiertas
- Puedes conservar un solo módulo o separar modelos y base de datos; justifica el grafo de imports que resulte.
- Puedes instrumentar el lifecycle con eventos, una factoría sustituible o un test unitario, siempre que no cambies el contrato HTTP.
Cómo revisar tu respuesta
- Los cinco tests de contrato pasan antes y después; POST sigue en 201 y GET/404 conservan body y status.
- Otra app construida sobre el mismo archivo recupera el activo y el archivo contiene una fila persistida.
- AssetCreate no acepta id, AssetPublic exige id y ningún body u OpenAPI expone internal_note.
- Existe un engine estable por app y una Session distinta por petición; no hay Session global mutable.
- La operación de escritura hace commit y refresh explícitos; la dependencia con yield garantiza cierre en éxito y error.
- create_all se usa solo como bootstrap local después de importar el modelo y la entrega declara que no migra esquemas.
Evidencia, revisión y reinicio
- Predicción de los cuatro ciclos de vida antes del cambio.
- Baseline verde, aceptación roja inicial y aceptación verde final.
- Traza o test propio de Session por petición y cierre en éxito y error.
- Inspección del archivo SQLite y respuesta pública después de recrear la app.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-02-assets.zip y borrar solo los archivos SQLite creados dentro de ese workspace temporal.