.net - Explicación del búfer/caché dapper

caching

Question

Uso dapper para devolver objetos de mi base de datos como IEnumerable. Como dapper por defecto tiene la configuración del buffer establecida en verdadero.

¿Como funciona esto?

Si dapper almacena en caché la primera consulta y luego obtiene los objetos de la memoria.

¿Qué sucede si alguien edita / elimina / agrega filas en la tabla? ¿Debe volver a almacenar todos los datos para esta consulta?

Answer 1

El búfer no está relacionado con la memoria caché. Dapper no incluye ningún tipo de caché de datos (aunque tiene un caché relacionado con la forma en que procesa los comandos, es decir, "esta cadena de comandos, con este tipo de parámetro y este tipo de entidad, tiene estos métodos asociados generados dinámicamente para configurar el comando y poblar los objetos ").

Lo que realmente significa este cambio es:

• false : iterará elementos a medida que se reciben / consumen, básicamente, un bloque iterador alrededor de un IDataReader
  • menos: solo puede iterarlo una vez (a menos que esté contento de volver a ejecutar la consulta)
  • Además: puede repetir consultas inmensas (muchos millones de filas), sin necesidad de todas ellas en la memoria a la vez, ya que solo está mirando realmente la fila actual que se está produciendo
  • plus: no es necesario que espere hasta el final de los datos para comenzar a iterar: tan pronto como tenga al menos una fila, estará listo para continuar
  • menos: la conexión está en uso mientras está iterando, lo que puede llevar a errores "ya hay un lector abierto en la conexión" (o lo que sea que la redacción exacta sea) si intenta invocar otros comandos en una fila por línea base (esto puede ser mitigado por MARS)
  • menos: porque el consumidor puede hacer lo que quiera por cada elemento (podría tomar minutos por fila, si está haciendo algo complejo), el comando / lector podría estar abierto por más tiempo
• true (valor predeterminado): los datos se consumen completamente en una List<T> antes de devolvérsela
  • plus: puedes repetirlo tantas veces como quieras
  • menos: si la consulta es inmensa, cargarlos todos en la memoria (en una lista) podría ser costoso / imposible
  • menos: si la consulta es grande, puede haber una latencia notable mientras recoge la última fila
  • más: una vez que obtiene los datos, el comando está completo, por lo que no hay conflicto entre eso y las operaciones posteriores
  • plus: tan pronto como obtenga los datos, el comando ya ha liberado los recursos (bloqueos, etc.), por lo que tiene un impacto mínimo en el servidor

La mayoría de las consultas solo devuelve una cantidad moderada de datos (por ejemplo, menos de 100 registros), por lo que estamos contentos de que el valor predeterminado ( true ) ofrezca el comportamiento más apropiado para la mayoría de los escenarios. Pero hacemos que la opción esté disponible para usted, para atender diferentes escenarios de uso.