Knex: एक बार में कई प्रश्नों को कैसे निष्पादित करें?

नहीं, आपको उन्हें दो कथनों के रूप में निष्पादित करना होगा।

खैर, यह थोड़ा सीमित समाधान है

आप क्वेरी पर toString() को कॉल करने और उसे निष्पादित करने का प्रयास कर सकते हैं, लेकिन मैं वास्तव में इसकी अनुशंसा नहीं करता हूं।

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

खैर, मैं देखूंगा कि इसके साथ क्या करना है, मूल रूप से मैं केवल तैयार बयानों को बंद करना चाहता हूं और क्वेरी स्ट्रिंग और बाइंडिंग रखने की क्षमता रखना चाहता हूं, लेकिन मुझे नहीं पता कि यह संभव है, मुझे इनसे संबंधित कोई दस्तावेज नहीं मिला।

वैसे भी, मैंने कोशिश की

knex.raw(query, bindings) + ''

लेकिन यह फेंकता है - ऑब्जेक्ट ऑब्जेक्ट की कोई विधि 'क्लोन' नहीं है।

यदि आप 0.6.0 शाखा को आजमाना चाहते हैं, तो मुझे पता है कि यह वहां काम करेगा, जिसे कुछ चीजों के लिए परीक्षण पूरा करने के बाद जारी किया जाना चाहिए।

हालांकि, क्या आपको इस तरह की एक स्ट्रिंग का उपयोग करके दो क्वेरी स्टेटमेंट निष्पादित करने की आवश्यकता होगी? क्या यह पैकेज का उपयोग करने के उद्देश्य को हराने जैसा नहीं है?

व्यक्तिगत रूप से, मुझे एक साथ कई INSERT ... ON DUPLICATE KEY UPDATE बनाने होंगे। मैं एकाधिक मानों के साथ एक सम्मिलित नहीं कर सकता क्योंकि मैं जानना चाहता हूं कि कौन सी पंक्ति अपडेट की गई है और कौन सी पंक्ति बनाई गई है (प्रभावित पंक्ति मान की जांच)।

Knex सीमाएं मिलने के बाद मैं नोड.जेएस के लिए विभिन्न क्वेरी बिल्डरों के साथ खेल रहा हूं (जिसके परिणामस्वरूप मूल रूप से ज्यादातर समय कच्चे प्रश्नों का उपयोग होता है)। अंत में मैंने सिर्फ sql बिल्डर को खुद कोड किया - QSql Demo । यह पूर्ण या उत्पादन के लिए तैयार नहीं है, लेकिन मूल रूप से मेरे सोचने के तरीके को संक्षेप में प्रस्तुत करता है।

बहुत अच्छा डेमो, मैं अगली रिलीज के बाद ऐसा कुछ जोड़ने की योजना बना रहा था - उत्सुक, क्या आपने 0.6 शाखा को आजमाया था?

मुझे आश्चर्य है कि यहां सहयोग के लिए कोई जगह है, जहां क्यूएसक्यूएल एक अधिक मजबूत क्वेरी बिल्डर की आवश्यकता को पूरा करने में सक्षम हो सकता है, जबकि क्नेक्स विभिन्न बोलियों के बीच मौसा पर कनेक्शन पूलिंग और चिकनाई से संबंधित है।

वैसे भी, अच्छा काम, मैं इसे देख लूंगा!

खैर नहीं, हमने 0.6 की कोशिश नहीं की क्योंकि हमारे पास एक ही स्थान पर knex का उपयोग करके बहुत सारे कोड थे और फिर कहीं और कुछ कच्चे प्रश्न कर रहे थे। कुछ शोध के बाद मैंने पूरे स्टैक को किसी ऐसी चीज से बदलने का फैसला किया जिसे बनाए रखा जा सकता है और जहां सुविधाओं को तुरंत जोड़ा जा सकता है।

खैर, मुझे लगता है कि सहयोग के लिए निश्चित रूप से एक जगह है, हालांकि पहले क्यूएसक्यूएल को स्थिर करने में कुछ समय लगेगा। मेरा मतलब एक अच्छा एपीआई परिभाषित करना है जो 99% जरूरतों और उपयोग-मामलों से मेल खाता है (जैसा कि आप देख सकते हैं कि कुछ संरचनाएं अभी भी थोड़ी बदसूरत हैं) और उचित अमूर्तता को लागू करने के लिए अन्य बैकएंड जोड़े जा सकते हैं।

शायद प्रश्नों की एक सरणी पास करने की क्षमता और फिर परिणाम एक सरणी भी है? इस तरह कुछ आसान अच्छा होगा, ऐसा करने के लिए async.parallel जैसे कुछ का उपयोग कर सकता है

@niftylettuce Bluebird पहले से ही "async.parallel" फीचर के साथ आता है। लेकिन यह समस्या नहीं है। हमें वास्तव में एक बार में कोमा से अलग किए गए प्रश्नों को निष्पादित करने का एक तरीका चाहिए।

क्या यह सिर्फ चिन्हित करने से संभव नहीं है

    multipleStatements: true

किसी के कॉन्फ़िगरेशन के कनेक्शन ब्लॉक में:
जैसे

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

ठीक है तो अगर यहां कोई दिलचस्पी लेता है - मैं इसे संभव बनाने के लिए आने वाले रिफैक्टर में कुछ नई चीजों पर काम कर रहा हूं।

मैं इस बारे में सोच रहा हूं कि इसके लिए आदर्श एपीआई क्या होगा ... क्या हम एक ही श्रृंखला रखना चाहते हैं?

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

  })

या कुछ और पसंद है:

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) => {

})

अर्धविराम पर विभाजित करके knex.raw केस को स्वचालित रूप से काम करने की संभावना को भी देखते हुए।

कच्चे प्रश्नों पर अर्धविराम पर विभाजन एक अच्छी शुरुआत होगी।

मैं अभी एक समस्या में भाग रहा हूं जहां मेरा डिलीट मेरे डालने से पहले समय पर पूरा नहीं हुआ है, इसलिए मुझे डुप्लिकेट कुंजी त्रुटियां फेंक दी जा रही हैं।

मैं कुछ ऐसा कर रहा हूँ

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

आपको सार मिल गया..

डेल समय पर पूरा नहीं होता है।

@tgriesser मेरा वोट knex.multiQuery के लिए है

@tgriesser एक ही प्रश्न में एकाधिक कथन निष्पादित करने की क्षमता पर कोई अपडेट? मैं चाहूंगा की:

अद्यतन ('रिकॉर्ड्स_रॉ')
.सेट ({शीर्षक: x})। जहां ({आईडी: 1})
।समाप्त()
अद्यतन ('रिकॉर्ड्स_रॉ')
.सेट ({शीर्षक: y})। जहां ({आईडी: 2})
तब (फ़ंक्शन (परिणाम) {
परिणाम [0] // परिणाम 1
परिणाम [1] // परिणाम 2
})
कैच (फ़ंक्शन (गलती) {
कंसोल.लॉग (गलती);
});

+1

अर्धविरामों पर उचित विभाजन करने के लिए, हमें बोली-विशिष्ट पार्सर का उपयोग करके संपूर्ण कच्ची क्वेरी को पार्स करना होगा। विशेष रूप से, यदि स्ट्रिंग्स में ; , तो उन्हें अनदेखा किया जाना चाहिए। यहां मान्य SQL के दो उदाहरण दिए गए हैं जो पार्स करने के लिए तुच्छ नहीं होंगे।

-- 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

यह भी ध्यान दें कि पहले मामले में हम 2 कथनों के साथ समाप्त होंगे, इसलिए कोड को विभाजन से खाली परिणामों को ध्यान में रखना होगा।

ईमानदारी से, कुल मिलाकर, मुझे लगता है कि यह एक बुरा विचार है। एसक्यूएल इंजेक्शन के लिए बहुत अधिक मौका है और प्रश्नों को सही ढंग से विभाजित नहीं करना है।

साथ ही, एकाधिक कथन निष्पादित करते समय, आप लगभग हमेशा चाहते हैं कि एक ही लेनदेन में ऐसा हो। Knex पहले से ही इस समस्या को .transacting(function(transaction) { /* code */ }) सिंटैक्स के साथ वास्तव में अच्छी तरह से हल करता है। दुर्लभ मामले में जहां आपको लेन-देन की आवश्यकता नहीं है, आप अपने knex स्टेटमेंट में शामिल होने और परिणाम प्राप्त करने के लिए बस ब्लूबर्ड का उपयोग कर सकते हैं।

तो इन मुद्दों के कारण, मेरी राय है कि ऐसा नहीं होना चाहिए।

:-1:

साथ ही, एकाधिक कथन निष्पादित करते समय, आप लगभग हमेशा चाहते हैं कि एक ही लेनदेन में ऐसा हो। Knex पहले से ही इस समस्या को .transacting(function(transaction) { /* code */ }) सिंटैक्स के साथ वास्तव में अच्छी तरह से हल करता है। दुर्लभ मामले में जहां आपको लेन-देन की आवश्यकता नहीं है, आप अपने knex स्टेटमेंट में शामिल होने और परिणाम प्राप्त करने के लिए बस ब्लूबर्ड का उपयोग कर सकते हैं।

मैं आपको अनुभव से बता सकता हूं कि कुछ मामलों में, इन दो दृष्टिकोणों के बीच एक _विशाल_ प्रदर्शन अंतर है और सर्वर पर एकाधिक मानों को एक कमांड के रूप में बैच करना है।

मैं समझता हूं कि इसे सफाई से लागू करना बहुत कठिन है, यही वजह है कि यह अभी तक नहीं किया गया है, लेकिन इस मुद्दे ने एक परियोजना के लिए मेरे knex के उपयोग को बहुत सीमित कर दिया है।

मेरे पास एक समान समस्या थी और इसे हल करने में सक्षम था। यहाँ पर देखें। https://github.com/tgriesser/knex/issues/1075

मैं इस सुविधा के लिए कोई उपयोगकेस देखने में असफल रहा हूं। इस टिकट को बंद करना पसंद करेंगे क्योंकि यह ठीक नहीं होगा। यदि कोई उसी कनेक्शन पर चल रहे प्रश्नों के क्रम पर निर्भर है तो आप शायद लेनदेन का उपयोग करना चाहते हैं।

एक चीज जो मैं देख रहा हूं वह इस 'एकाधिक क्वेरी' के उपयोग को किसी ऐसी चीज में बदल देती है जो हम चाहते हैं कि यह कुछ मामलों में संभावित प्रदर्शन जीत है। सर्वर से और उससे सभी प्रश्नों और परिणामों को संप्रेषित करने के लिए इसे कम राउंड-ट्रिप की आवश्यकता होती है।

लेकिन ऐसा नहीं है कि मेरे पास मापने योग्य उपयोग केस उपलब्ध है। केवल पिछले अनुभव/स्मृति से बोल रहा हूं ...

@ jurko-gospodnetic ऐसा तब हो सकता है जब आपके पास कनेक्शन पूलिंग न हो। पूलिंग के साथ कई प्रश्न भेजना मूल रूप से केवल पहले से बनाए गए टीसीपी सॉकेट में डेटा डालना है। इसके अलावा यदि आपका प्रदर्शन टीसीपी बफ़र्स पर पर्याप्त रूप से नहीं भरने पर निर्भर करता है तो knex आपके लिए पहले से ही बहुत धीमा है :) उस स्थिति में सीधे ड्राइवर का उपयोग करना बेहतर होता है।

@ जुरको-गोस्पोडनेटिक ने 20 मई को टिप्पणी की

एक चीज जो मैं देख रहा हूं वह इस 'एकाधिक क्वेरी' के उपयोग को किसी ऐसी चीज में बदल देती है जो हम चाहते हैं कि यह कुछ मामलों में संभावित प्रदर्शन जीत है। सर्वर से और उससे सभी प्रश्नों और परिणामों को संप्रेषित करने के लिए इसे कम राउंड-ट्रिप की आवश्यकता होती है।

मैं इस विशेष कारण से एंटरप्राइज़ ग्रेड प्रोजेक्ट पर नोड-mysql (mysqljs) का उपयोग कर रहा हूं। हम कई कारणों से पूरी परियोजना को knex.js पर माइग्रेट करना चाहते हैं

नोड-mysql (mysqljs) ड्राइवर की बहु-कथन क्वेरी सुविधा का लाभ उठाकर मैं इस तरह के संचालन पर काफी प्रदर्शन सुधार करता हूं।

अगर Knex इसका समर्थन नहीं करता है तो यह मेरे लिए शोस्टॉपर साबित हो सकता है। तो मैं बस यही पूछने के लिए इस सूत्र को पुनर्जीवित करूंगा।

क्या एक कथन में बहु-प्रश्न अब Knex.js में समर्थित हैं?

@nicholaswmin क्या आप थोड़ा और विशिष्ट बता सकते हैं कि "काफी प्रदर्शन सुधार" से आपका क्या मतलब है? एक ही कनेक्शन के माध्यम से कई प्रश्न भेजने की तुलना में इस तरह से कई प्रश्न कैसे भेजना काफी अधिक कुशल है? कोई बेंचमार्क?

@elhigu कोई बेंचमार्क नहीं लेकिन बल्ले से मैं यह कह सकता हूं:

डीबी को एक एकल कॉल (सभी बयानों के साथ पैक किया गया) सर्वर-डीबी नेटवर्क राउंड-ट्रिप को समाप्त कर देता है।

दूसरी ओर, एक ही कनेक्शन के माध्यम से कई प्रश्न भेजना चांदी की गोली नहीं है। यह समाधान केवल गैर-लेनदेन प्रवाह के साथ काम करेगा, यह समस्या देखें

@nicholaswmin क्या आप बड़ी मात्रा में छोटे प्रश्न भेज रहे हैं और अधिकतर अनदेखा या छोटे परिणाम भेज रहे हैं? उस स्थिति में मुझे लगता है कि अंतर ध्यान देने योग्य हो सकता है, क्योंकि यह ड्राइवर को प्रत्येक टीसीपी पैकेट में कई प्रश्नों को पैक करने की अनुमति देता है, जहां अन्यथा प्रत्येक टीसीपी पैकेट में ज्यादातर हेडर और वास्तव में बहुत कम पेलोड होगा।

उस तरह के प्रदर्शन अंतर को नेटवर्क ट्रैफ़िक की मात्रा से भी आसानी से मापा जा सकता है।

मुझे नहीं पता कि ड्राइवर पिछली कॉलों के परिणामों की प्रतीक्षा किए बिना अलग-अलग connection.query कॉल से डीबी को एकाधिक प्रश्न भेजने का समर्थन करते हैं या नहीं। यदि वे ऐसा करते हैं तो टीसीपी ट्रैफ़िक में एकाधिक connection.query या एकल बहु-क्वेरी भेजने के बीच बहुत अंतर नहीं होना चाहिए जो MySQL ड्राइवर द्वारा समर्थित है।

@elhigu वे वास्तव में छोटे प्रश्न हैं लेकिन उनके परिणामों की आवश्यकता है ताकि उन्हें लेनदेन/क्वेरी श्रृंखला के नीचे और उपयोग किया जा सके।

क्या मेरे लिए डिबग या इसी तरह के विकल्प के माध्यम से भेजे जा रहे टीसीपी पैकेट को देखने का कोई तरीका है? स्वयं भेजे जा रहे प्रश्न नहीं बल्कि वास्तविक पैकेट।

एक उपयोग मामला:

अपने सिस्टम में किसी उपयोगकर्ता के डेटा को अपडेट करते समय, मैं उस उपयोगकर्ता के लिए ऑडिट ट्रेल (क्या बदल गया है) की गणना करना चाहता हूं।

// # 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);

उपरोक्त प्रत्येक कॉल कई डीबी कॉल करता है, इसलिए जैसा कि आप कल्पना कर सकते हैं कि ये बहुत सारे नेटवर्क राउंडट्रिप हैं।

जैसा कि #1806 पर कहा गया है, मैं उन प्रश्नों के लिए Promise.all() का उपयोग करके इस पर काम कर सकता हूं जिन्हें अनुक्रमिक होने की आवश्यकता नहीं है (ज्यादातर getData/setData में डीबी कॉल अनुक्रमिक होने की आवश्यकता नहीं है)।

यह गैर-लेनदेन प्रवाह के साथ काम करेगा, क्योंकि पूल से विभिन्न कनेक्शनों पर प्रश्न भेजे जा सकते हैं। जैसे ही मैं उपरोक्त प्रवाह को करने के लिए लेनदेन का उपयोग करता हूं, यह धीमा हो जाता है (लगभग 4x) क्योंकि प्रश्न एक ही कनेक्शन पर भेजे जाते हैं।

एक साइड नोट के रूप में मैं एमएसएसक्यूएल का उपयोग कर रहा हूं।

Wireshark नेटवर्क ट्रैफ़िक का विश्लेषण करने के लिए उपयोग किया जाने वाला बहुत ही सामान्य क्रॉस-प्लेटफ़ॉर्म टूल है।

मुझे विश्वास नहीं है कि नोड के साथ उस स्तर तक देखने का कोई तरीका है।

एक प्रश्न में पैक किए गए प्रश्नों की समान मात्रा भेजते समय या ड्राइवर को अलग से पास करते समय भेजे गए / प्राप्त डेटा की मात्रा को मापने के लिए iptraf या किसी भी चीज़ का उपयोग करने का एक तरीका हो सकता है।

मुझे multiQuery सिंटैक्स देखना अच्छा लगेगा।

किसी भी अद्यतन ?
क्या अब मल्टीक्वेरी बनाना संभव है?
यदि हां, तो किस वाक्यविन्यास का उपयोग कर रहे हैं?

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...');

     // ...

यह सिर्फ एक लूप है, एक में कई अनुरोध नहीं किए गए हैं, और यह धीमा है

@mscheffer सवाल था:

मुझे एक समस्या का सामना करना पड़ रहा है कि मैं ';' से अलग किए गए कई प्रश्नों को निष्पादित करना चाहता हूं। एक निष्पादन द्वारा, क्या यह संभव है?

जो मेरा जवाब हल करता है। यदि आपके पास तेज़ बेहतर समाधान है तो कृपया इसे प्रदान करें।

@VictorioBerra ; से विभाजन सामान्य स्थिति में काम नहीं करता है, क्योंकि स्ट्रिंग अक्षर और टिप्पणियों के अंदर ; हो सकता है। यदि आप डेटा डंप में पढ़ रहे हैं, तो मैं कहूंगा कि एसक्यूएल डंप कोड को एसक्लाइट खोल में पाइप करना आसान तरीका है। अफसोस की बात है कि इन-मेमोरी डेटाबेस के लिए काम नहीं करता है, क्योंकि वे सिर्फ एक कनेक्शन हैं।

इसके अलावा आपके मामले में, जहां आप अंदर के टेम्पलेट स्ट्रिंग में एसक्यूएल स्ट्रिंग्स बना रहे हैं और फिर इसे विभाजित कर रहे हैं, knex.schema.* बिल्डरों का प्रभावी ढंग से एक ही चीज़ का उपयोग करके, लेकिन अधिक सुरक्षित।

जहां तक ​​​​मुझे पता है कि सभी बोली चालकों के लिए एकल आदेश में एकाधिक प्रश्न चलाने की इस सुविधा को प्राप्त करने का कोई तरीका नहीं है। मुझे लगता है कि यह MySQL और oracledb या mssql था, जिसका वह समर्थन था और MySQL के साथ आपको अभी भी प्रतिक्रिया के रूप में अंतिम क्वेरी का परिणाम मिलता है (जो ठीक हो सकता है)।

लेन-देन का उपयोग करना याद रखें यदि आप कई प्रश्नों का उपयोग करके डेटा को संशोधित कर रहे हैं ताकि आप सुनिश्चित कर सकें कि वे उत्तराधिकार में चलते हैं!

रॉ एसक्यूएल का उपयोग कर एकाधिक क्वेरी निष्पादन
मैं एक ऐसी ही स्थिति में भाग गया जहां हमारे knex माइग्रेशन में से एक को CREATE DATABASE लगातार कई बार चलाने की आवश्यकता थी। मैं अर्धविराम से प्रश्नों को अलग करने की आशा करता था, लेकिन knex ने एक वाक्यविन्यास त्रुटि फेंक दी। इसका समाधान आपके कनेक्शन ऑब्जेक्ट में "multipleStatements": true है, इसलिए इसका अंतिम परिणाम इस तरह दिख सकता है:

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

उसके बाद, आप इस तरह एक कच्चे बयान का उपयोग कर सकते हैं:

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

KNEX क्वेरी बिल्डर का उपयोग करके एकाधिक क्वेरी निष्पादन
यदि आपको कच्चे SQL को स्वयं लिखने के बजाय knex क्वेरी बिल्डर का उपयोग करने की आवश्यकता है, तो आपको परिणामों को Knex.QueryBuilder में एक स्ट्रिंग में बदलना होगा, और फिर एक साथ कई प्रश्नों को जोड़ना होगा। यहाँ एक उदाहरण है:

// 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) => {
   });

यह अनावश्यक प्रश्नों को लिखते समय मानवीय त्रुटि को कम करने में भी मदद करता है जिन्हें उत्तराधिकार में निष्पादित करने की आवश्यकता होती है। फिर से कुछ इस तरह से मैं इसे एक लेनदेन में लपेटने का सुझाव दूंगा।

मुझे लगता है कि इसे बंद किया जा सकता है क्योंकि यह ज्यादातर डीबी ड्राइवरों द्वारा सीमित है। कम से कम उचित सुविधा अनुरोध की आवश्यकता है।

@अक्षराकारिकालन भले ही आप उनके बीच कई