Fuente local con Room: consultas que devuelven Flow

La diferencia entre una base de datos usada como almacén y una base de datos usada como fuente de verdad cabe en el tipo de retorno de una función. Si una consulta devuelve una lista, quien la llama obtiene una fotografía tomada en un instante y contrae de inmediato la obligación de volver a preguntar cuando sospeche que algo cambió; toda la coordinación de cuándo refrescar queda en sus manos, y ese es el origen de la mayoría de las pantallas que muestran datos viejos. Si esa misma consulta devuelve Flow, la relación se invierte: quien la llama declara una vez qué le interesa y la base de datos asume la responsabilidad de avisar cada vez que la respuesta deja de ser válida. No es azúcar sintáctico ni una comodidad reactiva de moda. Es un traslado de responsabilidad desde el consumidor, que no puede saber cuándo cambian los datos, hacia el único componente del sistema que lo sabe con certeza porque es quien ejecuta las escrituras.

Una consulta que no termina nunca

Cuando un método de un objeto de acceso a datos declara Flow como tipo de retorno, la librería genera una implementación distinta de la habitual. En lugar de ejecutar la sentencia y devolver el resultado, registra un observador sobre las tablas que la consulta menciona y produce un flujo que emite el resultado inicial y, después, un resultado nuevo cada vez que alguna de esas tablas se modifica.

@Dao
interface CatalogoDao {

    @Query("SELECT * FROM producto WHERE categoria = :categoria ORDER BY nombre")
    fun observar(categoria: String): Flow<List<ProductoEntity>>

    @Query("SELECT * FROM producto WHERE id = :id")
    fun observarUno(id: String): Flow<ProductoEntity?>
}

Merece la pena entender la granularidad real de esa invalidación, porque casi todo el mundo la sobreestima. El disparo no ocurre por fila ni por consulta: ocurre por tabla. Cualquier inserción, actualización o borrado sobre producto reejecuta las dos consultas del ejemplo, incluidas aquellas cuyo resultado no ha cambiado en absoluto. La librería no compara resultados por ti; se limita a saber que algo pudo cambiar y a volver a preguntar. Esa elección es deliberada: comprobar si un cambio afecta a una consulta concreta exigiría interpretar la sentencia y mantener índices sobre los criterios, un coste desproporcionado frente al de reejecutar una consulta indexada sobre una base local.

De ahí se sigue una consecuencia práctica que aparece en cuanto la aplicación crece. Si una pantalla observa una tabla que otro proceso escribe con frecuencia, recibirá emisiones que no le aportan nada, y cada una de ellas provocará mapeo, comparación y posiblemente recomposición. El primer remedio no es reactivo sino relacional: consulta solo las columnas que necesitas y filtra en la sentencia en vez de en Kotlin, de modo que dos resultados consecutivos sean idénticos con más frecuencia. El segundo, complementario, es distinctUntilChanged, que corta la emisión cuando el valor mapeado es igual al anterior; funciona porque los modelos de dominio son data class con igualdad estructural, y ese es uno de los motivos por los que interesa que lo sean.

Escrituras que no publican incoherencias

Que la base emita en cuanto una tabla cambia tiene una cara incómoda: si una operación lógica se compone de varias escrituras, cada una de ellas puede disparar una emisión intermedia que muestre un mundo a medio construir. Borrar el catálogo anterior e insertar el nuevo en dos llamadas separadas produce, entre ambas, un instante perfectamente observable en el que la pantalla dice que no hay productos.

@Transaction
suspend fun reemplazarCategoria(categoria: String, nuevos: List<ProductoEntity>) {
    borrarPorCategoria(categoria)
    insertar(nuevos)
}

La anotación transaccional resuelve las dos mitades del problema a la vez. Garantiza atomicidad frente a fallos, que es lo que todo el mundo espera de ella, y además agrupa la invalidación: los observadores no reciben nada hasta que la transacción confirma, y entonces reciben un único resultado ya coherente. Sin ella, la pantalla parpadea; con ella, transita de un estado válido a otro sin pasar por ninguno inválido.

sequenceDiagram
participant R as Repositorio
participant D as Room
participant O as Observador de la UI
R->>D: transaccion borrar mas insertar
D-->>O: sin emisiones durante la transaccion
R->>D: confirmar
D-->>O: unica emision con la lista final
Note over O: cero estados intermedios visibles

Conviene entender también el reverso de esa garantía, porque tiene un coste que se paga en escrituras masivas. Agrupar la invalidación significa que durante una transacción larga los observadores no reciben nada, de modo que una sincronización de diez mil filas ejecutada en una sola transacción deja la pantalla congelada en el estado anterior hasta que termina. Para importaciones grandes suele ser preferible trocear en transacciones por lote, aceptando emisiones intermedias que son coherentes aunque parciales, y mostrar el progreso. La elección entre una transacción grande y varias pequeñas no es de rendimiento sino de qué incoherencias resultan tolerables: las parciales sí, las inválidas nunca.

Hay una segunda regla que evita la mitad de las incoherencias restantes: preferir la escritura idempotente a la secuencia de borrado e inserción. Una operación de inserción con reemplazo sobre la clave primaria, o un upsert, deja la tabla en el estado deseado sin destruir antes lo que ya era correcto, y por tanto no invalida filas que no cambiaron. Además sobrevive mejor a la repetición: si una sincronización se ejecuta dos veces por un reintento, el resultado es el mismo, mientras que un borrado seguido de inserción abre una ventana durante la cual un fallo deja la tabla vacía.

La entidad se queda dentro

Una entidad de persistencia y un modelo de dominio se parecen lo suficiente como para que resulte tentador usar el mismo tipo para ambos, y son distintos en todo lo que importa. La entidad existe para satisfacer al motor de almacenamiento: tipos primitivos, columnas planas, claves foráneas, ausencia de jerarquías selladas, campos técnicos como marcas de tiempo de sincronización. El modelo existe para expresar el negocio: tipos propios, valores obligatorios, estados imposibles eliminados por construcción.

@Entity(tableName = "producto")
data class ProductoEntity(
    @PrimaryKey val id: String,
    val nombre: String,
    val precioCentimos: Long,
    val categoria: String,
    val actualizadoEn: Long,
)

fun ProductoEntity.aDominio() = Producto(
    id = ProductoId(id),
    nombre = nombre,
    precio = Dinero(precioCentimos),
    categoria = CategoriaId(categoria),
)

El mapeador vive en la capa de datos y es una función pura, lo que lo hace comprobable con una tabla de casos y sin base de datos. Su presencia parece un impuesto hasta el primer cambio de esquema: cuando alguien añade una columna, divide un campo o renombra una tabla, todo el impacto queda contenido en esa función. Sin ella, la migración se propaga a cada when de cada reducer que mencionara el campo antiguo.

La separación también protege en la dirección contraria, que se olvida con más frecuencia. El dominio quiere tipos que hagan imposibles los estados inválidos, y eso incluye jerarquías selladas, valores envueltos y colecciones no vacías; el motor de almacenamiento quiere columnas planas de tipos primitivos. Intentar satisfacer ambas exigencias con una sola clase termina siempre igual: el dominio se degrada a cadenas y enteros para que la persistencia funcione, y con esa degradación se pierden precisamente las garantías que justificaban tipar el dominio. Es el mismo modelo pobre de siempre, adoptado no por convicción sino por comodidad de almacenamiento.

El coste real de observar

Observar no es gratis, y conviene conocer la factura antes de suscribir media aplicación a la base de datos. Cada consulta observada mantiene una entrada en el registro de invalidación, y cada emisión implica ejecutar la sentencia, construir objetos, mapearlos y comparar.

La última tarjeta merece un desarrollo, porque es la que más consumo silencioso provoca. Un flujo coleccionado en el ViewModel con un ámbito que vive mientras vive la pantalla sigue activo aunque la aplicación esté en segundo plano, y con ella siguen activas las consultas que la invalidación dispara. La combinación correcta consiste en publicar el estado con una política de compartición que se detenga tras un breve margen sin suscriptores y en coleccionar desde la interfaz atendiendo al ciclo de vida. Así, cuando nadie mira, la suscripción a la base se cancela y la consulta deja de ejecutarse; cuando la pantalla vuelve, la primera emisión llega inmediatamente con el contenido actual.

Queda una decisión de diseño que se toma mal con frecuencia: dónde colocar la transformación. Mapear dentro del flujo, con map sobre el resultado del objeto de acceso a datos, mantiene el trabajo en el contexto de la corrutina que colecciona, que por defecto es el del ViewModel. Para listas cortas es irrelevante; para listas de miles de elementos conviene mover explícitamente la conversión al ejecutor de entrada y salida con flowOn, que reubica el trabajo de todo lo que está aguas arriba sin afectar a quien colecciona.

override fun observarProductos(categoria: CategoriaId): Flow<List<Producto>> =
    dao.observar(categoria.valor)
        .map { filas -> filas.map(ProductoEntity::aDominio) }
        .distinctUntilChanged()
        .flowOn(io)

Esas cuatro líneas son, en la práctica, la implementación entera de la lectura en una arquitectura orientada a la fuente local. No hay lógica de refresco, no hay decisión sobre la red, no hay caché manual: hay una suscripción a la tabla y una traducción. Toda la complejidad que la mayoría de las aplicaciones ponen en esta función se ha desplazado al camino de escritura, y esa es exactamente la reorganización que la cuarta lección de este nivel convertirá en principio.