Knex: Comment exécuter plusieurs requêtes en une seule fois ?

Non, vous devrez les exécuter comme deux instructions.

Eh bien, c'est une solution un peu limite

Vous pouvez essayer d'appeler toString() sur la requête et de l'exécuter, mais je ne le recommande pas vraiment.

knex.raw(knex.raw(query, bindings) + '').exec(function(err, result) {
  assert.isNotError(err);
});

Eh bien, je vais voir quoi faire avec cela, en gros, je voudrais simplement désactiver les instructions préparées et conserver la possibilité d'avoir une chaîne de requête et des liaisons, mais je ne sais pas si c'est possible, je n'ai trouvé aucune documentation à ce sujet.

En tout cas j'ai essayé

knex.raw(query, bindings) + ''

mais il jette - L'objet objet n'a pas de méthode 'clone'.

Si vous voulez essayer la branche 0.6.0, je sais que cela fonctionnera là-bas, cela devrait être publié une fois les tests terminés pour quelques choses.

Mais pourquoi auriez-vous besoin d'exécuter deux instructions de requête en utilisant une seule chaîne comme celle-ci ? Cela ne va-t-il pas en quelque sorte à l'encontre du but de l'utilisation du package ?

Personnellement, je dois faire plusieurs INSERT ... ON DUPLICATE KEY UPDATE à la fois. Je ne peux pas faire d'insertion avec plusieurs valeurs car je veux savoir quelle ligne a été mise à jour et quelle ligne a été créée (en vérifiant la valeur de la ligne affectée).

J'ai joué avec divers générateurs de requêtes pour node.js après avoir trouvé les limitations de Knex (qui résultaient essentiellement en l'utilisation de requêtes brutes la plupart du temps). En fin de compte, je viens de coder le constructeur SQL moi-même - QSql Demo . Ce n'est pas terminé ou prêt pour la production, mais résume essentiellement ma façon de penser.

Démo très cool, j'avais prévu d'ajouter quelque chose comme ça après la prochaine version - curieux, aviez-vous essayé la branche 0.6 ?

Je me demande s'il y a une place pour la collaboration ici, où QSQL pourrait être en mesure de répondre au besoin d'un générateur de requêtes plus robuste, tandis que Knex s'occupe de la mise en commun des connexions et du lissage des failles entre les différents dialectes.

En tout cas, beau travail, je vais jeter un œil !

Eh bien non, nous n'avons pas essayé la 0.6 car nous avions beaucoup de code utilisant knex à un endroit, puis faisant des requêtes brutes ailleurs. Après quelques recherches, j'ai décidé de remplacer l'ensemble de la pile par quelque chose qui peut être maintenu et où des fonctionnalités peuvent être ajoutées instantanément.

Eh bien, je pense qu'il y a définitivement une place pour la collaboration, mais il faudra un certain temps pour stabiliser QSql d'abord. Je veux dire définir une belle API qui correspond à 99% des besoins et des cas d'utilisation (comme vous pouvez le voir, certaines constructions sont encore un peu laides) et implémenter une abstraction appropriée afin que d'autres backends puissent être ajoutés.

peut-être la possibilité de transmettre un tableau de requêtes et les résultats sont également un tableau ? quelque chose de simple comme celui-ci serait cool, pourrait utiliser quelque chose comme async.parallel pour le faire

@niftylettuce Bluebird est déjà livré avec la fonctionnalité "async.parallel" prête à l'emploi. Mais ce n'est pas le problème. Nous avons vraiment besoin d'un moyen d'exécuter des requêtes séparées par des virgules en une seule fois.

N'est-ce pas possible en marquant simplement

    multipleStatements: true

dans le bornier de sa configuration :
par exemple

    connection: {
        host: 'localhost',
        user: 'superSecret',
        password: 'notGonnaTell',
         port: 8889,
        database: 'babelverse_core',
        multipleStatements: true
    }

D'accord, si quelqu'un ici est intéressé, je travaille sur de nouvelles choses dans le prochain refactor pour rendre cela possible.

Je me demande quelle serait l'API idéale pour cela... voulons-nous avoir une seule chaîne ?

knex
  .update('records_raw')
  .set({title: x}).where({id: 1})
  .end()
  .update('records_raw')
  .set({title: y}).where({id: 2})
  .spread((resultA, resultB) => {

  })

ou quelque chose comme :

knex.multiQuery([
  knex.update('records_raw').set({title: x}).where({id: 1})
  knex.update('records_raw').set({title: y}).where({id: 2})
]).spread((resultA, resultB) => {

})

Nous cherchons également à rendre possible le fonctionnement automatique du cas knex.raw en le divisant sur le point-virgule.

Le fractionnement en point-virgule sur les requêtes brutes serait un bon début.

Je rencontre actuellement un problème où ma suppression n'est pas terminée à temps avant mon insertion, donc je reçois des erreurs de clé en double.

je fais quelque chose comme

knex("mytable")
.where({
  id: 32423
})
.del()
.then( ->
  knex("mytable")
  .insert()
 ..... 

vous voyez l'essentiel..

Le del ne se termine pas à temps.

@tgriesser mon vote est pour knex.multiQuery

@tgriesser une mise à jour sur la possibilité d'exécuter plusieurs instructions dans une seule requête ? Je préférerais:

.update('records_raw')
.set({title : x}).where({id : 1})
.finir()
.update('records_raw')
.set({title : y}).where({id : 2})
.then(fonction(résultat) {
résultat[0] //résultat 1
résultat[1] // résultat 2
})
.catch(fonction(err) {
console.log(err);
});

+1

Afin d'effectuer une division appropriée sur les points-virgules, nous aurions besoin d'analyser l'intégralité de la requête brute à l'aide d'un analyseur spécifique au dialecte. Plus précisément, si les chaînes contiennent ; , elles doivent être ignorées. Voici deux exemples de SQL valide qui ne serait pas trivial à analyser.

-- generic SQL
SELECT * FROM book WHERE title = 'Lord of the Rings; The Fellowship of the Ring';

-- MySQL specific
CREATE PROCEDURE dorepeat(p1 INT)
  BEGIN
    SET <strong i="9">@x</strong> = 0;
    REPEAT SET <strong i="10">@x</strong> = <strong i="11">@x</strong> + 1; UNTIL <strong i="12">@x</strong> > p1 END REPEAT;
  END

Notez également que dans le premier cas, nous nous retrouverions avec 2 instructions, le code devrait donc prendre en compte les résultats vides de la scission.

Honnêtement, dans l'ensemble, je pense que c'est une mauvaise idée. Il y a tout simplement trop de chances pour l'injection SQL et ne pas diviser correctement les requêtes.

De plus, lors de l'exécution de plusieurs instructions, vous souhaitez presque toujours que cela se produise dans la même transaction. Knex résout déjà très bien ce problème avec la syntaxe .transacting(function(transaction) { /* code */ }) . Dans les rares cas où vous n'avez pas besoin d'une transaction, vous pouvez simplement utiliser bluebird pour joindre vos relevés knex et obtenir les résultats.

Donc, à cause de ces problèmes, mon opinion est que cela ne devrait pas arriver.

:-1:

De plus, lors de l'exécution de plusieurs instructions, vous souhaitez presque toujours que cela se produise dans la même transaction. Knex résout déjà très bien ce problème avec la syntaxe .transacting(function(transaction) { /* code */ }) . Dans les rares cas où vous n'avez pas besoin d'une transaction, vous pouvez simplement utiliser bluebird pour joindre vos relevés knex et obtenir les résultats.

Je peux vous dire par expérience que dans certains cas, il existe une différence de performances énorme entre ces deux approches et le traitement par lots de plusieurs valeurs sur le serveur en une seule commande.

Je comprends que c'est très difficile à mettre en œuvre proprement, c'est pourquoi cela n'a pas encore été fait, mais ce problème a considérablement limité mon utilisation de knex pour un projet.

J'ai eu un problème similaire et j'ai pu le résoudre. Voir par ici. https://github.com/tgriesser/knex/issues/1075

Je ne vois aucun cas d'utilisation pour cette fonctionnalité. J'adorerais fermer ce ticket car cela ne résoudra pas. Si l'un dépend de l'ordre des requêtes exécutées sur la même connexion, vous souhaiterez probablement utiliser des transactions.

La seule chose que je vois qui fait de cette utilisation de « requêtes multiples » quelque chose que nous aimerions avoir, c'est qu'il s'agit d'une amélioration potentielle des performances dans certains cas. Il nécessite moins d'allers-retours pour communiquer toutes les requêtes et les résultats vers et depuis le serveur.

Mais ce n'est pas comme si j'avais un cas d'utilisation mesurable disponible. Ne parlant que d'expérience/mémoire passée...

@jurko-gospodnetic Cela peut être le cas lorsque vous n'avez pas de pool de connexion. Avec la mise en commun, l'envoi de plusieurs requêtes consiste essentiellement à mettre des données sur un socket TCP déjà créé. De plus, si vos performances dépendent du fait que les tampons TCP ne sont pas suffisamment remplis, alors knex est déjà trop lent pour vous :) Dans ce cas, il vaut mieux utiliser directement le pilote.

@jurko-gospodnetic a commenté le 20 mai

La seule chose que je vois qui fait de cette utilisation de « requêtes multiples » quelque chose que nous aimerions avoir, c'est qu'il s'agit d'une amélioration potentielle des performances dans certains cas. Il nécessite moins d'allers-retours pour communiquer toutes les requêtes et les résultats vers et depuis le serveur.

J'utilise node-mysql (mysqljs) sur un projet de niveau entreprise pour cette raison particulière. Nous cherchons à migrer l'ensemble du projet vers knex.js pour une multitude de raisons

Il y a une amélioration considérable des performances sur de telles opérations que je tire en tirant parti de la fonctionnalité de requêtes à instructions multiples du pilote node-mysql (mysqljs) .

Cela pourrait s'avérer un obstacle pour moi si Knex ne prend pas en charge cela. Je vais donc relancer ce fil pour demander juste cela.

Les requêtes multiples dans une seule instruction sont-elles désormais prises en charge dans Knex.js ?

@nicolaswmin pouvez-vous dire un peu plus précisément ce que vous entendez par « amélioration considérable des performances » ? En quoi l'envoi de plusieurs requêtes de cette manière est considérablement plus efficace que le simple envoi de plusieurs requêtes via la même connexion ? Des repères ?

@elhigu Pas de repères mais d'

Un seul appel à la base de données (avec toutes les instructions) élimine les allers-retours réseau serveur-db.

D'un autre côté, envoyer plusieurs requêtes via la même connexion n'est pas une solution miracle. Cette solution ne fonctionnerait qu'avec des flux non transactionnels, voir ce numéro

@nicolaswmin Envoyez -vous une énorme quantité de petites requêtes et la plupart du temps des résultats ignorés ou petits ? Dans ce cas, je suppose que la différence peut être perceptible, car elle permet au pilote de regrouper plusieurs requêtes pour chaque paquet TCP, où sinon chaque paquet TCP aurait principalement des en-têtes et une très petite quantité de charge utile.

Ce type de différence de performances devrait pouvoir être mesuré facilement, même à partir de la quantité de trafic réseau.

Je ne sais pas si les pilotes prennent en charge l'envoi de plusieurs requêtes à partir d'appels connection.query distincts vers la base de données sans attendre au préalable les résultats des appels précédents. S'ils le font, il ne devrait pas y avoir beaucoup de différence dans le trafic TCP entre l'envoi de plusieurs connection.query ou une seule multi-requête qui est prise en charge par le pilote mysql.

@elhigu Ce sont en effet de petites requêtes, mais leurs résultats sont nécessaires pour pouvoir être utilisés plus loin dans la chaîne de transaction/requête.

Existe-t-il un moyen pour moi de voir les paquets TCP envoyés via un débogage ou une option similaire ? Pas les requêtes elles-mêmes envoyées, mais les paquets réels.

Un cas d'utilisation :

Lors de la mise à jour des données d'un utilisateur dans mon système, j'aimerais calculer la piste d'audit (ce qui a changé) pour cet utilisateur.

// # PSEUDOCODE

// get current data of user
getUserData();
// set data of user
setUserData()
// get new data of user
getUserData()
// compute the audit trail by comparing the difference between before-set/after-set datums
computeAuditTrail(previousData, newData);

Chacun des appels ci-dessus effectue plusieurs appels de base de données, vous pouvez donc imaginer qu'il s'agit de nombreux allers-retours réseau.

Comme indiqué sur #1806, je peux contourner ce problème en utilisant Promise.all() pour les requêtes qui n'ont pas besoin d'être séquentielles (la plupart des appels de base de données dans getData/setData n'ont pas besoin d'être séquentiels).

Cela fonctionnerait avec des flux non transactionnels, car les requêtes peuvent être envoyées sur différentes connexions à partir du pool. Dès que j'utilise une transaction pour effectuer le flux ci-dessus, il ralentit (environ 4x) puisque les requêtes sont envoyées sur une seule connexion.

En remarque, j'utilise MSSQL.

Wireshark est un outil multiplateforme assez courant utilisé pour analyser le trafic réseau.

Je ne crois pas qu'il y ait un moyen d'atteindre ce niveau avec node.

Une façon pourrait être d'utiliser iptraf ou quoi que ce soit pour mesurer la quantité de données envoyées / reçues lors de l'envoi du même nombre de requêtes avec une seule requête ou transmis séparément au pilote.

J'aimerais voir une syntaxe multiQuery .

Toute mise à jour ?
Est-il possible maintenant de faire du multiQuery ?
Si oui, avec quelle syntaxe ?

var knex = require("knex");
var _ = require("lodash");
var Promise = require("bluebird");

var knex = require('knex')({
    client: 'sqlite3',
    connection: {
        filename: "./data.sqlite"
    }
});

// Create Schema
let createScript = `

CREATE TABLE Class ( 
    Id                   integer NOT NULL  ,
    Name                 varchar(100)   ,
    CONSTRAINT Pk_Classes_Id PRIMARY KEY ( Id )
 );

CREATE TABLE Material ( 
    Id                   integer NOT NULL  ,
    Description          varchar(500)   ,
    CONSTRAINT Pk_Material_Id PRIMARY KEY ( Id )
 )

-- ... and so on (leave off the last semi or remove it later) ... 

`;

let statementPromises = _.map(createScript.split(';'), (statement) => {
    return knex.raw(statement);
});

Promise.all(statementPromises).then(function() {
    console.log('Schema generated. Populating...');

     // ...

c'est juste une boucle, pas plusieurs requêtes en une seule, et c'est LENT

@mscheffer la question était :

Je suis confronté à un problème que je voudrais exécuter plusieurs requêtes séparées par ';' par un seul exec, est-ce possible ?

Ce que ma réponse résout. Si vous avez une meilleure solution plus rapide, veuillez la fournir.

@VictorioBerra Le fractionnement à partir de ; ne fonctionne pas dans le cas général, car il peut y avoir ; intérieur des littéraux de chaîne et des commentaires. Si vous lisez dans un vidage de données, je dirais que le moyen le plus simple consiste à rediriger le code de vidage SQL vers le shell sqlite. Malheureusement, cela ne fonctionne pas pour les bases de données en mémoire, car il ne s'agit que d'une seule connexion.

Également dans votre cas, où vous créez des chaînes SQL dans une chaîne de modèle à l'intérieur, puis la divisez, en utilisant les constructeurs knex.schema.* effectivement la même chose, mais plus sécurisée.

Pour autant que je sache, il n'y a aucun moyen d'obtenir cette fonctionnalité d'exécution de plusieurs requêtes en une seule commande pour tous les pilotes de dialecte. Je pense que c'était mysql et oracledb ou mssql, qui avaient ce support et avec mysql, vous n'obtenez toujours que le résultat de la dernière requête en tant que réponse (ce qui pourrait être correct cependant).

N'oubliez pas d'utiliser des transactions si vous modifiez des données à l'aide de plusieurs requêtes afin de vous assurer qu'elles s'exécutent successivement !

EXÉCUTION DE REQUÊTES MULTIPLES À L'AIDE DE RAW SQL
J'ai rencontré une situation similaire où l'une de nos migrations knex devait exécuter CREATE DATABASE plusieurs fois de suite. J'espérais séparer les requêtes par des points-virgules, mais knex a renvoyé une erreur de syntaxe. La solution pour cela est d'inclure "multipleStatements": true dans votre objet de connexion, donc le résultat final peut ressembler à ceci :

"host": "192.168.x.x",
"user": "userLogin",
"password": "userPassword",
"database": "schemaToUse",
"multipleStatements": true

Après cela, vous pouvez utiliser une instruction brute comme ceci :

return knex.raw("CREATE DATABASE schema0; CREATE DATABASE schema1; CREATE DATABASE schema2")
   .then((result) => {
   })
   .catch((error) => {
   });

EXÉCUTION DE REQUÊTES MULTIPLES À L'AIDE DE KNEX QUERY BUILDER
Si vous devez utiliser le générateur de requêtes knex au lieu d'écrire vous-même le code SQL brut, vous devez convertir les résultats en Knex.QueryBuilder en une chaîne, puis joindre plusieurs requêtes. Voici un exemple :

// Suppose that we wanted to add 100 currency for all players in multiple games
const addCurrency = 100;
const updateCurrency = { currency: "currency + " + addCurrency };
const queries = [
   knex.table("game0.stats").update(updateCurrency),
   knex.table("game1.stats").update(updateCurrency),
   knex.table("game2.stats").update(updateCurrency),
];
const multiQuery = queries.join(";");
console.log(multiQuery);
return knex.raw(multiQuery)
   .then((result) => {
   })
   .catch((error) => {
   });

Cela permet également de réduire les erreurs humaines lors de l'écriture de requêtes redondantes qui doivent être exécutées successivement. Encore une fois, avec quelque chose comme ça, je suggérerais de l'envelopper dans une transaction.

Je pense que cela peut être fermé car cela est principalement limité par les pilotes db. Au moins une demande de fonctionnalité appropriée est nécessaire.

@AksharaKarikalan même si vous effectuez plusieurs sous-requêtes et soustractions entre celles-ci, vous ne faites toujours qu'une seule requête. J'ai donc supprimé le commentaire qui n'a rien à voir avec ce problème. Stackoverflow est le bon endroit pour les demandes d'utilisation de knex.