Práctica focalizada · Bloque 4 · Unidad 4.2
EX-B4-04
Reparar un PATCH que confunde ausencia con null
Una 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.
Cómo abordarla
Conserva intención al consultar y cambiar
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 la matriz omitido/null/valor de la ventana SQL con filtro, orden, count, limit y offset observables.
Abrir laboratorio de código
1. Descarga y arranca
- Starter con PATCH defectuosoAPI SQLModel ya persistente, cinco pruebas de continuidad verdes y tres casos de presencia visibles; uno empieza rojo.
2. Escribe y prueba
- Predice los tres resultados y ejecuta baseline y aceptación sin editar.
- Inspecciona el conjunto de campos explícitos que Pydantic conserva para cada body.
- Aplica únicamente esos cambios a la fila y conserva commit y refresh observables.
- Repite las suites y registra por qué null sigue siendo un cambio válido.
3. Demuestra el comportamiento
- Corrección mínima y pruebas finales.
- Matriz prevista/observada para omitido, null y valor.
- Fingerprint de POST, GET, PATCH y 404 antes y después.
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é información de presencia conserva Pydantic antes del dump y qué conjunto exacto debe recibir sqlmodel_update?
Matriz de presencia
Estado inicial location=Madrid. PATCH {} conserva Madrid; PATCH con null deja null; PATCH con Bilbao deja Bilbao.Comprueba estas tres cosas
- ¿Qué valor esperas después de PATCH {}?
- ¿Qué debe ocurrir con location: null si el campo es nullable?
- ¿Qué cambia entre model_dump() y model_dump(exclude_unset=True)?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Observa antes de mutar
- Imprime o prueba payload.model_fields_set para {} y para {location: null}.
- El valor None no dice por sí solo si el cliente envió el campo.
Pista 2 · Conserva solo lo explícito
- model_dump(exclude_unset=True) produce el parche, no el estado completo.
- sqlmodel_update aplica ese conjunto, pero no decide permisos ni confirma la transacción.
Profundización opcional
Distinguir campo omitido, null explícito y valor antes de mutar la fila, sin cambiar el contrato de creación, lectura o ausencia.
Contexto adicional
- Ejecuta primero el baseline verde y después los tres casos de aceptación.
- Repara solo la extracción y aplicación de cambios explícitos; no amplíes el modelo update.
- Conserva POST 201, GET/404, response_model y la ausencia de internal_note en HTTP y OpenAPI.
Decisiones abiertas
- Puedes inspeccionar model_fields_set o el dump con exclusión; compara ambas opciones antes de elegir.
Cómo revisar tu respuesta
- Los cinco tests de continuidad permanecen verdes y los tres criterios de presencia terminan verdes.
- Un body vacío no modifica location; null explícito la borra y un valor explícito la sustituye.
- El conjunto entregado a sqlmodel_update procede de model_dump(exclude_unset=True) o una técnica equivalente demostrable.
- PATCH sobre un id ausente conserva 404 y no crea una fila.
- internal_note no se puede asignar desde el body ni aparece en la representación pública.
Evidencia, revisión y reinicio
- Matriz omitido, null y valor predicha antes de ejecutar.
- Cinco pruebas de continuidad verdes y un criterio focalizado inicialmente rojo.
- Diff mínimo y respuestas observadas para los tres estados de presencia.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-04-patch-intent.zip y eliminar solo la base SQLite creada dentro de ese workspace.