Saltar al contenido

donde destruir la conexion knex

Contamos con el arreglo a este asunto, al menos eso deseamos. Si presentas dudas déjanoslo saber en un comentario y sin dudar

Solución:

Knex destroy() parece ser una operación única. Después de destruir una conexión, es posible que se requiera un grupo de conexiones completamente nuevo para la siguiente operación.

El módulo de cliente de base de datos que exporta se almacena en la memoria caché del módulo de nodo y no se crea un nuevo grupo de conexiones cada vez que lo necesita.

Este es el uso previsto, se supone que el grupo se destruye cuando la aplicación sale o se realizan todas las pruebas. Si tiene motivos para crear/destruir conexiones para cada operación (como en un entorno sin servidor), no debe reutilizar el cliente destruido, sino crear una nueva instancia cada vez.

De lo contrario, anula el propósito de la agrupación de conexiones.


Actualizar sobre entornos lambda/sin servidor:

Técnicamente, una función y sus recursos deben liberarse después de que se haya ejecutado la función lambda, esto incluye cualquier conexión que pueda haber abierto. Esto es necesario para funciones verdaderamente sin estado. Por lo tanto, es aconsejable cerrar la conexión cuando se realiza la función. Sin embargo, muchas funciones que abren/cierran muchas conexiones pueden eventualmente hacer que el servidor de base de datos se quede sin conexiones (consulte esta discusión, por ejemplo). Una solución podría ser usar un grupo intermedio como PgBouncer o PgPool que negocie las conexiones entre el servidor DB y las funciones de Lambda.

La otra forma es que el proveedor de la plataforma (AWS) agregue capacidades de agrupación especiales al entorno lambda y les permita compartir recursos de larga duración.

Probablemente no necesite llamar explícitamente knex.destroy() – esto está implícito en la propia documentación que dice (énfasis mío):

Si alguna vez necesitas derribar explícitamente el grupo de conexiones, puede usar knex.destroy([callback]).

Destruir la conexión después de cada consulta es como empaquetar tu guitarra cada vez que tocas una nota. Solo sáquelo al comienzo de la presentación, reproduzca todas las canciones y guárdelo al final.

Del mismo modo, destruya la conexión cuando haya terminado con ella para el resto de la aplicación, no después de cada consulta como esta. En un servidor web, esto probablemente nunca ocurra, ya que lo eliminará con una señal en algún punto indeterminado y es probable que una conexión activa sea necesaria para la aplicación hasta entonces.

Para las pruebas, probablemente querrá hacer uso de la destroy Función para evitar colgar. Del mismo modo, en una aplicación (¿artificial?) como la que ha mostrado, si experimenta un bloqueo y la aplicación se atasca, destruya la conexión una vez que haya terminado con ella.

Aquí hay un ejemplo ilustrativo para Mocha, que se mencionó en un comentario y parece una suposición bastante razonable de que (o algo similar) está siendo utilizado por personas que terminan en este hilo. El patrón de configuración antes de todas las pruebas, desmontaje después de todas las pruebas y configuración y desmontaje por caso de prueba es genérico.

Relevante a su pregunta, after(() => knex.destroy()); es la llamada de desmontaje al final de todas las pruebas. Sin esto, Mocha cuelga. Tenga en cuenta que también apagamos el servidor http por prueba, por lo que hay múltiples candidatos para colgar el conjunto de pruebas a tener en cuenta.

server.js:

const express = require("express");

const createServer = (knex, port=3000) => 
  const app = express();
  
  app.get("/users/:username", (request, response) => 
    knex
      .where("username", request.params.username)
      .select()
      .first()
      .table("users")
      .then(user => user ? response.json(data: user)
                         : response.sendStatus(404))
      .catch(err => response.sendStatus(500))
  );
  
  const server = app.listen(port, () =>
    console.log(`[server] listening on port $port`)
  );
  return 
    app,
    close: cb => server.close(() => 
      console.log("[server] closed");
      cb && cb();
    )
  ;
;
module.exports = createServer;

server.test.js:

const chai = require("chai");
const chaiHttp = require("chai-http");
const createServer = require("./server");
const expect = chai;
chai.use(chaiHttp);
chai.config.truncateThreshold = 0;

describe("server", function () 
  this.timeout(3000);
  let knex;
  let server;
  let app;
  
  before(() => 
    knex = require("knex")(
      client: "pg",
      connection: "postgresql://[email protected]",
    );
  );
  beforeEach(done => 
    server = createServer(knex);
    app = server.app;
    knex
      .schema
      .dropTableIfExists("users")
      .then(() => 
        knex.schema.createTable("users", table => 
          table.increments();
          table.string("username");
        )
      )
      .then(() => knex("users").insert(
        username: "foo"
      ))
      .then(() => done())
      .catch(err => done(err));
  );
  afterEach(done => server.close(done));
  after(() => knex.destroy());
  
  it("should get user 'foo'", done => 
    chai
      .request(app)
      .get("/users/foo")
      .then(response => 
        expect(response.status).to.equal(200);
        expect(response).to.be.json;
        expect(response.body).to.be.instanceOf(Object);
        expect(response.body.data).to.be.instanceOf(Object);
        expect(response.body.data.username).to.eq("foo");
        done();
      )
      .catch(err => done(err));
  );
);

Paquetes:

"knex": "0.21.6",
"express": "4.17.1",
"mocha": "8.0.1",
"pg": "8.3.0",    
"node": "12.19.0"

Reseñas y puntuaciones de la guía

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *