CAPÍTULO 3 · Cada pieza encuentra su responsabilidad
Dar identidad a lo que vamos a administrar
Con una base disponible, es tentador comenzar agregando columnas. Sin embargo, SensorHub necesita reconocer sus objetos a lo largo del tiempo. Un sensor puede cambiar de ubicación o de descripción sin convertirse por eso en otro sensor. Si su identidad depende de un texto que alguien puede editar, las relaciones y los históricos se vuelven difíciles de mantener.
Definimos identificadores y examinamos el uso de UUID. También aparecen atributos compartidos, como fechas de creación o modificación. En vez de copiarlos a cada modelo, una base abstracta puede concentrar su definición. La abstracción empieza aquí con una necesidad pequeña y visible: conservar de forma uniforme lo que varias entidades tienen en común.
Ya podemos hablar de una estación y de un sensor con identidad propia. Pero guardarlos por separado no nos dice si una lectura pertenece a un sensor válido o si una combinación de datos debe ser única. Para que el catálogo represente el negocio, las entidades necesitan relaciones y límites que sobrevivan a cualquier pantalla.
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
Un molde para identidades únicas
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Base abstracta. Comparte campos comunes
- UUID. Identidad estable
- Sensor. Hereda la base
- Estación. Hereda la base
01 / EL PROBLEMA
¿Para qué sirve?
Repetir campos comunes aumenta el trabajo de mantenimiento. Una clase abstracta expresa un contrato uniforme para las entidades.
02 / COMPRENDER
El concepto, explicado
La herencia abstracta copia campos al modelo concreto sin una tabla padre. La herencia multitabla tiene otro comportamiento y añade joins.
UUID evita depender de una secuencia global de enteros para los enlaces, pero no concede privacidad. created_at registra cuándo se guardó el objeto.
03 / CONSTRUIR
Implementación paso a paso
- Crea una app common para infraestructura compartida.
- Define BaseModel abstracto.
- Hereda desde Station y Sensor.
- Genera y revisa las migraciones.
04 / APLICAR
Ejemplo en SensorHub
# common/models.py
import uuid
from django.db import models
class BaseModel(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
created_at = models.DateTimeField(auto_now_add=True)
class Meta:
abstract = TrueCómo leer el ejemplo
- default recibe uuid.uuid4, sin paréntesis: Django lo llama para cada objeto nuevo.
- editable=False limita edición en formularios; los permisos son una responsabilidad diferente.
- abstract=True evita crear common_basemodel.
Error habitual
Un UUID no sustituye verificar que el usuario puede consultar ese objeto.
05 / PRACTICAR
Tu turno
Añade updated_at al modelo base.
Ver solución orientativa
Usa DateTimeField(auto_now=True), revisa la migración y recuerda que QuerySet.update no ejecuta Model.save.
06 / VERIFICAR
Cómo sabes que funciona
- Dos entidades obtienen UUID diferentes.
- No existe una tabla del modelo abstracto.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Relaciones y reglas de integridad →Continuar en modo relato