CAPÍTULO 5 · Ver un botón no concede permiso
Confirmar una vez lo que debe ocurrir junto
Imaginemos que una operación necesita guardar una lectura y actualizar información relacionada. Si una parte se confirma y la otra falla, el sistema conserva un resultado difícil de interpretar. También puede suceder que el cambio se complete, pero el cliente no reciba la respuesta y vuelva a intentarlo. La segunda petición no necesariamente representa una intención nueva.
Las transacciones nos ayudan a delimitar qué cambios deben confirmarse juntos. La idempotencia permite reconocer reintentos cuando el caso de uso lo requiere. No aplicamos ambas palabras como una receta universal: definimos qué significa una operación completa y qué identidad permite distinguir una repetición de un nuevo evento.
Con estas decisiones, el catálogo y sus comandos están mejor preparados para condiciones reales. Ya podemos pasar de la administración humana al origen principal de los datos de SensorHub. Los dispositivos traerán mediciones bajo ritmos y formas de conexión distintos a los de una persona que navega por la plataforma.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una operación que confirma una vez
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Solicitud. Incluye identidad de operación
- Idempotencia. Detecta intentos repetidos
- Transacción. Coordina cambios atómicos
- Resultado. Confirma o revierte el conjunto
01 / EL PROBLEMA
¿Para qué sirve?
Un timeout no significa que el servidor no guardó. El cliente puede reintentar y producir dos lecturas o dos alarmas si la operación no tiene identidad.
02 / COMPRENDER
El concepto, explicado
Idempotencia significa que repetir la misma intención no produce efectos adicionales. Una clave de evento única puede identificar cada lectura.
atomic agrupa escrituras, pero dos transacciones pueden competir. Una restricción única o un bloqueo correcto mantiene la invariante. get_or_create necesita unicidad real en su lookup.
03 / CONSTRUIR
Implementación paso a paso
- Define la identidad de la lectura.
- Declara unicidad en base de datos.
- Usa un servicio de ingesta transaccional.
- Devuelve si se creó o ya existía.
04 / APLICAR
Ejemplo en SensorHub
# En el modelo Reading:
# event_key = models.UUIDField(unique=True)
@transaction.atomic
def store_reading(*, sensor, event_key, occurred_at, value):
reading, created = Reading.objects.get_or_create(
event_key=event_key,
defaults={"sensor": sensor, "occurred_at": occurred_at, "value": value},
)
if not created and (reading.sensor_id != sensor.pk or reading.value != value):
raise ValueError("La clave ya se usó para otro contenido.")
return reading, createdCómo leer el ejemplo
- La clave identifica una intención, no cualquier contenido distinto que la reutilice.
- Una implementación completa debe comparar también fecha y los demás campos relevantes.
- La restricción de base de datos evita duplicados en carreras concurrentes.
Error habitual
Capturar cualquier IntegrityError como “ya existía” puede ocultar otra restricción rota. Identifica la causa.
05 / PRACTICAR
Tu turno
Envía dos veces una misma lectura y luego la misma clave con otro valor.
Ver solución orientativa
La repetición idéntica retorna el objeto existente; la clave reutilizada con contenido diferente se rechaza.
06 / VERIFICAR
Cómo sabes que funciona
- Dos solicitudes idénticas dejan una sola lectura.
- Una clave no cambia silenciosamente el contenido histórico.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Ingesta IoT y credenciales técnicas →Continuar en modo relato