R2DBC: ¿Los resultados de las consultas son reactivos/emitidos en flujo?
Estoy probando el stack reactivo con MySQL en el backend.
Esperaba que los resultados de la consulta fueran un flujo, es decir, una consulta pesada no esperaría y devolvería el resultado cuando se encuentren todos los registros, sino que los enviaría uno por uno en forma de flujo. No parece que sea así. El proceso espera hasta que finalice la consulta y luego devuelve todos los resultados.
Este es el repositorio de Spring Data que he creado:
public interface ScopusSpringDataRepo extends ReactiveCrudRepository<scopus, long=""> {
@Query("select SC1.* from Scopus as SC1 join Scopus as SC2"
+ " on SC1.norma like concat(SC2.norma, '%') where ( SC2.norma is not null"
+ " and SC2.word like concat('%', :word, '%'))")
public Flux<scopus> byNorma(String word);
}
Esta consulta es pesada a propósito.
¿Alguien puede explicar qué comportamiento se espera de R2DBC en este caso?
Gracias.
Actualización después de los comentarios:
El método byNorma del repositorio es llamado por un servicio de negocio que a su vez es llamado por un controlador REST.
Servicio:
public class ScopusService {
protected ScopusSpringDataRepo scRepo;
public Flux<scopus> getByNorma(String norma) {
return scRepo.byNorma(norma);
}
}
Controlador REST:
public class ScopusController {
protected ScopusService scopusService;
@GetMapping(path = "/stream/scopus/{word}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public ResponseEntity<><scopus>> getByNorma(@PathVariable String word) {
log.info("Getby norma recieved. word :{}", word);
return ResponseEntity.ok(this.scopusService.getByNorma(word));
}
}
Que es llamado desde un navegador Chromium.
Actualización:
Estoy tratando de entender si el controlador R2DBC envía los resultados uno por uno o simplemente los obtiene todos primero y luego los envía de una vez en el flujo.</scopus,>
davy.ai
Según los fragmentos de código proporcionados, parece que el controlador R2DBC está esperando a que la consulta se complete y luego enviando todos los resultados a la vez en lugar de transmitirlos uno por uno. Este comportamiento podría deberse a la implementación subyacente del controlador R2DBC o al propio servidor MySQL.
Sin embargo, vale la pena señalar que el comportamiento de un flujo reactivo también está influenciado por la forma en que se consume el flujo. En este caso, el método
byNormade la interfazScopusSpringDataRepodevuelve unFlux<scopus>. El métodogetByNormade la claseScopusServicedevuelve esteFlux<scopus>directamente al controlador REST. Luego, el controlador REST devuelve esteFlux<scopus>como el cuerpo de la respuesta con el tipo de contenidoMediaType.TEXT_EVENT_STREAM_VALUE.Si bien es válido devolver un
Fluxcomo cuerpo de respuesta en un punto final reactivo, también es importante considerar cómo se consume el flujo por parte del cliente. En los fragmentos de código proporcionados, parece que el flujo está siendo consumido por un navegador Chromium. Vale la pena señalar que no todos los clientes pueden manejar una respuesta de transmisión, y el comportamiento del flujo también puede depender de factores como la latencia de la red y la carga del servidor.En resumen, aunque el controlador R2DBC puede no estar transmitiendo los resultados de la consulta uno por uno, el comportamiento del flujo también puede verse influenciado por la forma en que el flujo es consumido por el cliente.