Knex: मानक ES6 प्रॉमिस का उपयोग करने के लिए कैसे कॉन्फ़िगर करें?

जिज्ञासु: आप एक तेज लाइब्रेरी को धीमे बिल्ट-इन से बदलना चाहते हैं? क्लाइंट पर इससे कोई फर्क नहीं पड़ेगा लेकिन नोड स्पीड में एक कारक है। इसके लिए आपका क्या तर्क है?

@johanneslumpe यह कुछ अनुप्रयोगों में कारक है, knex के साथ मुझे अत्यधिक संदेह है कि Promise लाइब्रेरी का उपयोग प्रदर्शन पर कोई महत्वपूर्ण प्रभाव डालता है। यह चर्चा की गई है कि हमें केवल ए+ एपीआई का उपयोग करने के लिए सभी Promise कोड लिखना चाहिए ताकि bluebird की आवश्यकता न हो।

उसके बाद ओवरराइड करना आसान होना चाहिए, जो Promise लाइब्रेरी का उपयोग किया जाता है।

मैं मानता हूँ कि यह knex जैसी लाइब्रेरी में व्यर्थ लगता है। यह देखते हुए कि knex का कोडबेस पहले से ही अपना खुद का वादा .js फ़ाइल आंतरिक रूप से आयात करता है, यह तकनीकी रूप से अभी भी लागू करना बहुत आसान होगा, बशर्ते एपीआई समान _ (जो मुझे यकीन नहीं है कि यह है?)_। इस फ़ाइल में कोई वैश्विक वादों के लिए डिफ़ॉल्ट हो सकता है, अन्यथा कॉन्फ़िगर की गई लाइब्रेरी की आवश्यकता होती है, या ऐसा कुछ।

यह सब उपयोगकर्ताओं को एक विकल्प देने के बारे में है; नोड V6+ उपयोगकर्ताओं के लिए, यथासंभव कम से कम तृतीय पक्ष निर्भरता को प्रबंधित करने का विकल्प दें।

जिज्ञासु: आप एक तेज लाइब्रेरी को धीमे बिल्ट-इन से बदलना चाहते हैं?

आप जो कह रहे हैं वह अतीत में सच हो सकता है, लेकिन अब या 6 महीने बाद कैसा रहेगा? (मैंने कुछ खोज की और केवल 2015 के कुछ बेंचमार्क का पता लगा सकता है, यदि आपके पास हाल की तुलना है, तो कृपया कुछ लिंक पोस्ट करें)
मेरा मानना ​​​​है कि प्रॉमिस को ES6 मानक बनाने का पूरा बिंदु लोगों के लिए आसानी से प्रॉमिस का उपयोग करने के लिए है, किसी तीसरे पक्ष के पुस्तकालय पर भरोसा नहीं करना है, और नोड या V8 की कोर टीम हमेशा के लिए प्रदर्शन अंतर से अंधी नहीं हो सकती है, जब तक कि दो परियोजनाओं के ओपन सोर्स लाइसेंस संगत हैं, वे कुछ कोड उधार भी ले सकते हैं; या बस उन्हें कुछ समय दें मेरा मानना ​​है कि बिल्टिन प्रॉमिस तेज और बेहतर हो सकता है।

अमेज़ॅन का एडब्ल्यूएस-एसडीके देखें: वैश्विक स्तर पर उपलब्ध किसी भी वादे का उपयोग करने के लिए यह भी डिफ़ॉल्ट है; जबकि उपयोगकर्ता को पसंदीदा प्रॉमिस लाइब्रेरी को भी कॉन्फ़िगर करने का विकल्प दें

http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-making-requests.html#Support_for_Promises

यह सब विकल्पों के बारे में है

दूसरे विचार पर, यह एक फ़ाइल को बदलने जितना आसान नहीं होगा। क्नेक्स वर्तमान में ब्लूबर्ड उपयोगिता कार्यों जैसे .timeout , .tap , .reduce , .map आदि पर बहुत कुछ निर्भर करता है, जो मैं मान रहा हूं और अस्तित्व में नहीं होने की उम्मीद कर रहा हूं ES6 वादों में।

मुझे ES6 वादों का समर्थन करने में दिलचस्पी है। आदर्श रूप से हमें Knex Promise लेता है। बैक संगतता इस प्रकार प्राप्त की जाएगी:

const Promise = require('bluebird');
const knex = Knex(myKnexConfig, Promise);

शायद हम आपूर्ति किए गए Promise.prototype पर उनकी उपस्थिति के आधार पर सशर्त उपनाम map , filter आदि कर सकते हैं?

मुझे लगता है कि यह प्राथमिकता सूची में बहुत कम होना चाहिए, और इसके लिए काफी कुछ आंतरिक परिवर्तनों की आवश्यकता होगी, प्रदर्शन में कमी का उल्लेख नहीं करने के लिए (हालांकि स्वीकार्य रूप से थोड़ी देर में बेंचमार्क नहीं देखा गया है) और तथ्य यह है कि लोग भरोसा कर सकते हैं इस तथ्य पर कि लौटाए गए वादे एक ब्लूबर्ड हैं (सशर्त catch , आदि के लिए)।

मैं इसे संबोधित करने के लिए एक स्थिर नोड में async/प्रतीक्षा भूमि तक प्रतीक्षा करने के इच्छुक हूं।

लोगों के लिए न्यूनतम तृतीय पक्ष निर्भरता चाहते हैं, मूल वादा बेहतर हो सकता है,

@google-cloud और कई अन्य पुस्तकालयों की तरह, आप मूल वादे का उपयोग करने के लिए इसे डिफ़ॉल्ट बना सकते हैं और एक वादा पैरामीटर स्वीकार कर सकते हैं जिसके लिए तृतीय पक्ष पुस्तकालयों का उपयोग करना चाहते हैं

https://googlecloudplatform.github.io/google-cloud-node/#/docs/google -cloud/

var gcloud = require('google-cloud')({
  promise: require('bluebird')
});

@tgriesser मुझे पता है कि यह एक पुराना मुद्दा है, लेकिन अब हमें स्थिर और कार्बन दोनों में async / await मिल गया है।

यह देखते हुए कि यह एसिंक के लिए पसंद किया जाता है/मूल वादों के साथ काम करने की प्रतीक्षा करता है ( कल्पना के अनुसार, async फ़ंक्शंस को मूल वादा वापस करना होगा ) क्या यह कोई उच्च प्राथमिकता है?

यदि मूल वादा समर्थन कुछ ऐसा है जो Knex होना चाहता है, लेकिन यह वर्तमान में रडार पर नहीं है, तो क्या पीआर का स्वागत किया जाएगा?

आपके समय के लिए धन्यवाद।

@malexdev async फ़ंक्शंस मूल वादे लौटाते हैं, जिसका वर्तमान में knex से कोई लेना-देना नहीं है। इसका मतलब यह नहीं है कि await को ठीक से काम करने के लिए मूल वादों की आवश्यकता है। क्या आप स्पष्ट कर सकते हैं कि यह किस मामले में एक समस्या/लाभ है (एक निर्भरता को छोड़कर)?

कहा जा रहा है कि मैं ब्लूबर्ड छोड़ने के खिलाफ नहीं हूं, लेकिन इसे वास्तव में काफी आंतरिक बदलावों की जरूरत है। हमें कुछ विधियों को लागू करने की आवश्यकता हो सकती है जो वर्तमान में bluebird से knex APIs तक उजागर होती हैं, जब तक कि कुछ कॉन्फ़िगरेशन स्विच के तहत पुरानी कार्यक्षमता छिपी न हो और डिफ़ॉल्ट रूप से मूल वादों का उपयोग किया जाएगा। इस तरह से माइग्रेट करना उन लोगों के लिए असंभव नहीं होगा जो इस तथ्य पर भरोसा कर रहे हैं कि knex bluebird वादे लौटाता है।

@elhigu मेरे लिए व्यक्तिगत रूप से मुख्य लाभ यह है कि मैं टाइपस्क्रिप्ट का उपयोग एक TSLint नियम के साथ कर रहा हूं, जो await के लिए उपयोग किए जा रहे मूल वादों को लागू करता है, इसलिए मुझे सभी Knex कॉल को Promise.resolve() के अंदर लपेटना होगा। मुझे एहसास है कि यह विशेष रूप से क्नेक्स के साथ कुछ भी नहीं करना है, और संभवतः मेरे लिए एक अद्वितीय मुद्दा है।

इसके अलावा मेरी राय में तीसरे पक्ष की निर्भरता कम होना बेहतर है, और जैसा कि @ c0b ने उल्लेख किया है कि अधिक विकल्प कभी भी बुरी बात नहीं है।

मुझे एहसास है कि यह बहुत काम होगा, यही एक कारण है कि मैं इस पर समय बिताने से ज्यादा खुश हूं, अगर यह ऐसा कुछ है जो Knex की ओर बढ़ने में रुचि रखता है।

हाँ, मैं यहाँ एक टाइपस्क्रिप्ट समस्या से आया हूँ - मैं अपने मल्टी-स्टोरेज डेटास्टोर लाइब्रेरी के लिए SQL इंजन के रूप में Knex का उपयोग कर रहा हूँ, और जब मैं मूल निवासी बनाम ब्लूबर्ड वादों के विपरीत हूँ, तो मैं आसानी से उपयोग नहीं कर सकता इस कारण से knex पर टाइपप्रति। मैं मूल कल्पना का पालन करने के रूप में नेक्स थैनेबल्स का इलाज करता हूं (मैं किसी भी ब्लूबर्ड एक्सटेंशन का उपयोग नहीं करता), लेकिन टाइपस्क्रिप्ट मुझे ब्लूबर्ड वापस करने के बारे में बताता हैजब विधि घोषणा एक वादा है.

यह यहां दो तरह के गहरे स्तर हैं, क्योंकि हम दोनों वादे कार्यान्वयन और knex के लिए टाइपिंग (जो विभिन्न देवों द्वारा नियंत्रित किए जाते हैं) के साथ काम कर रहे हैं, लेकिन मैं मूल रूप से यहां फंस गया हूं - मैं तकनीकी रूप से टाइप अनुबंध को तोड़ रहा हूं जब मैंने वादा घोषित किया है तो ब्लूबर्ड लौटा रहा है (मुझे लगता है कि वादा एपीआई में सामान है जो ब्लूबर्ड समर्थन नहीं करता है?) लेकिन मुझे वास्तव में हर जगह return Promise.resolve(bluebirdthing) का गुच्छा डालने का मन नहीं है।

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

यह सब async/प्रतीक्षा के साथ फैंसी होने के बाद भी अच्छा होगा, और मैं इसे ठीक करने की जल्दी में नहीं हूं (आखिरकार मेरे उपयोग के मामले में मैं चीजों को any के रूप में फ़्लैग कर रहा हूं और उनसे निपट रहा हूं कोडब्रांच जैसे कि वे टाइपस्क्रिप्ट के बजाय जावास्क्रिप्ट थे)।

@ericeslinger मैं नहीं देखता कि वास्तविक वादा कार्यान्वयन का उपयोग क्यों किया जा रहा है, टाइपस्क्रिप्ट के साथ समस्याएं पैदा करेगा, मैं ब्लूबर्ड और देशी वादों को बिना किसी समस्या के डेढ़ साल से मिला रहा हूं ...

मैं बस किसी भी टाइपिंग का उपयोग नहीं कर रहा हूं जो ब्लूबर्ड के लिए प्रकार पेश करेगा, मैं सिर्फ टाइपस्क्रिप्ट टाइपिंग बताता हूं कि वे सामान्य वादे हैं और इसमें कोई अंतर नहीं दिखता है (अगर मैं ब्लूबर्ड की विशेष विधियों का उपयोग करने का प्रयास करता हूं तो यह शिकायत करेगा)।

कौन सा टाइपस्क्रिप्ट संस्करण है और क्या पुन: पेश करने के लिए कोई उदाहरण प्रोजेक्ट है ... उदाहरण के लिए एनपीएम स्टार्ट स्क्रिप्ट के साथ जीथब रेपो।

यह यहां दो तरह के गहरे स्तर हैं, क्योंकि हम दोनों वादे कार्यान्वयन और knex के लिए टाइपिंग (जो विभिन्न देवों द्वारा नियंत्रित किए जाते हैं) के साथ काम कर रहे हैं, लेकिन मैं मूल रूप से यहां फंस गया हूं - मैं तकनीकी रूप से टाइप अनुबंध को तोड़ रहा हूं एक ब्लूबर्ड लौटा रहा है जब मैंने एक वादा घोषित किया है (मुझे लगता है कि वादा एपीआई में सामान है जो ब्लूबर्ड समर्थन नहीं करता है?) लेकिन मुझे वास्तव में हर जगह वापसी का एक गुच्छा डालने का मन नहीं है। हर जगह हल करें (ब्लूबर्डिंग)।

क्या वे knex टाइपिंग npm से हैं? क्या ब्लूबर्ड टाइपिंग एनपीएम से हैं? कौन से पैकेज? मुझे यह समझने में मुश्किल हो रही है कि ऐसा क्यों होगा। यदि अलग ब्लूबर्ड प्रकार है तो इसे मूल वादे से विरासत में प्राप्त किया जाना चाहिए और एपीआई से वापस आना ठीक है जो बताता है कि वे वादा वापस कर देंगे। विवरण से ऐसा लगता है कि समस्या बहुत टूटी हुई टाइपिंग कार्यान्वयन है। और यह इस मुद्दे के लिए प्रासंगिक नहीं है (टाइपस्क्रिप्ट वास्तविक प्रकारों के बारे में बुरा नहीं मानता है, इसलिए यह नहीं पता होगा कि knex क्या लौटाता है)।

मैं @types/knex इंस्टॉल करके निश्चित रूप से टाइप किए गए रेपो से अपनी टाइपिंग प्राप्त कर रहा हूं। वह परिभाषा इसके साथ खींचती है @types/bluebird , और सभी knex विधियों को ब्लूबर्ड ऑब्जेक्ट लौटने के रूप में टाइप किया जाता है।

एक विशिष्ट चीज़ के रूप में, मैं यह नहीं कर सकता:

function mungeData(v: any): DataItem {} 
function foo(): Promise<DataItem[]> {
  return knex('data').select()
  .then((rows) => rows.map(row => mungeData(row)))
} // error, cannot return Bluebird<DataItem[]> as Promise<DataItem[]>

इन टाइपिंग का उपयोग करना। ऐसा इसलिए है क्योंकि knex.select().then() को निश्चित रूप से टाइप किए गए रेपो में एक ब्लूबर्ड वापस करने के लिए टाइप किया गया है, और उन श्रृंखलाओं को एक साथ अधिक ब्लूबर्ड बनाने के लिए, और return foo as Promise<any>() जैसा कुछ कह रहा है जब फू ब्लूबर्ड हैविफल हो जाएगा (कम से कम यह टाइपस्क्रिप्ट 2.4 में विफल रहता है), क्योंकि ब्लूबर्ड्स प्रॉमिस के लिए असाइन करने योग्य नहीं हैं (उनके अनुसार [Symbol.toStringTag] की कमी है , इसलिए एक को दूसरे के साथ जबरदस्ती करना एक छोटी सी त्रुटि के बावजूद त्रुटि होगी)।

इसके बजाय मैं बदल सकता हूँ

function bar(): Promise<DataItem[]> {
  return Promise.resolve<DataItem[]>(foo())
}

या देशी Promise.resolve() कॉल के अंदर सभी कॉल्स को knex में लपेटने के लिए अन्य तरकीबें करें। यह टाइपस्क्रिप्ट को मेरे लाइब्रेरी फ़ंक्शंस के डाउनस्ट्रीम में शिकायत करना बंद कर देगा, जबकि मुझे अभी भी अपने लाइब्रेरी फ़ंक्शंस के अंदर knex टाइपिंग का उपयोग करने की अनुमति देगा।

कल से पहले, मैंने @types/knex का बिल्कुल भी उपयोग नहीं किया था - मैं केवल any के रूप में knex टाइप कर रहा था। कोड रनटाइम पर किसी भी तरह से ठीक काम करता है (कम से कम मेरे उपयोग के मामले के लिए), यह बस है

@elhigu : मुद्दा टाइपिंग कार्यान्वयन टूटा नहीं है।
टाइपस्क्रिप्ट async फ़ंक्शन के प्रकार को Promise<[type]> के रूप में सेट करता है, जो प्रति JS स्पेक के लिए सही है।
Knex Bluebird<[type]> लौटाता है, जिसे टाइपिंग सटीक रूप से दर्शाती है।

मैं अभी किसी भी टाइपिंग का उपयोग नहीं कर रहा हूं जो ब्लूबर्ड के लिए प्रकार पेश करेगा, मैं सिर्फ टाइपस्क्रिप्ट टाइपिंग बताता हूं कि वे सामान्य वादे हैं और इसमें कोई अंतर नहीं दिखता है

यह संकलक के लिए झूठ बोल रहा है, क्योंकि क्नेक्स फ़ंक्शन वास्तव में Bluebird s लौटाते हैं। रुचि नहीं।
आप सही हैं कि ब्लूबर्ड वादों के अनुकूल हैं, लेकिन टाइपस्क्रिप्ट के साथ सौदे का एक हिस्सा यह है कि आप वास्तव में वही लौटाते हैं जो आप कहते हैं कि आप लौट रहे हैं।

एक फ़ंक्शन से Bluebird लौटाते समय जिसे $#$5$# Promise वापस करने के लिए टाइप किया गया है, टाइपस्क्रिप्ट शिकायत करता है क्योंकि टाइप Bluebird टाइप Promise के समान नहीं है।
ऐसी कई तरकीबें हैं जो हम कर सकते हैं (जैसे कि @ericeslinger ने any का उपयोग करने के बारे में क्या उल्लेख किया है, या Promise.resolve() में लपेटकर) लेकिन दिन के अंत में इस तरह की चालें हमें बहुत कुछ खो देती हैं टाइपस्क्रिप्ट क्या प्रदान करता है।

दिन के अंत में, वास्तविकता यह है कि अब कम से कम दो उपयोगकर्ता हैं जो कह रहे हैं "मूल वादों का उपयोग करना हमारे लिए महत्वपूर्ण है, और हम वादे की कार्यक्षमता को और अधिक सामान्य बनाने के लिए काम करने को तैयार हैं"।

मुझे एहसास है कि आप सिर्फ मदद करने की कोशिश कर रहे हैं, लेकिन स्पष्ट रूप से सुनने के बजाय "आप इसे इस तरह से कर सकते हैं" मैं यह सुनना चाहता हूं कि क्या मेरे द्वारा प्रस्तावित वादे में बदलाव / @ericeslinger / @ c0b स्वीकार्य हैं ताकि मैं या तो शुरू कर सकूं एक जनसंपर्क पर या क्या।

@malexdev @ericeslinger अधिक जानकारी के लिए धन्यवाद! ऐसा लगता है कि यह वास्तव में Promise से आपकी अपनी कक्षा का उत्तराधिकारी संभव नहीं है, इसलिए यही कारण हो सकता है कि ब्लूबर्ड को उस फ़ंक्शन से वापस करना जो वादा <> विफल होने के लिए टाइप किया गया है :(

@ericeslinger वैसे भी यह कोई समस्या नहीं है जब आप async फ़ंक्शन बनाते हैं, क्योंकि वे आंतरिक रूप से मूल वादों के परिणामों को स्वचालित रूप से लपेटते हैं। निम्नलिखित बिना किसी समस्या का अनुपालन करता है, @types/bluebird से टाइपिंग के साथ और ES2015 या ESNEXT में संकलित।

import * as Bluebird from 'bluebird';

// declaring function async converts bluebird implicitly to native Promise
async function asyncReturningPromise(): Promise<string> {
    const blueBirdPromise = new Bluebird<string>((resolve, reject) => { 
        resolve('yay asyncReturningPromise');    
    });
    return blueBirdPromise;
}

// main func to run the code using async / await
Bluebird.resolve().then(async () => {
    console.log("await function returning promise (bluebird)", await asyncReturningPromise());

    const blueBird = new Bluebird((resolve, reject) => { resolve(); });
    const returnedFromAsync = asyncReturningPromise();

    console.log("Bluebird instanceof Promise:", blueBird instanceof Promise);
    console.log("async retval instanceof Promise:", returnedFromAsync instanceof Promise);
});

आउटपुट:

await function returning promise (bluebird) yay asyncReturningPromise
Bluebird instanceof Promise: false
async retval instanceof Promise: true

तो अभी के लिए जब आप अभी के लिए knex API का उपयोग कर रहे हैं, तो आपको वास्तव में यह बताने की आवश्यकता है कि आप ब्लूबर्ड वापस कर रहे हैं जब तक कि आप async फ़ंक्शन/विधियों का उपयोग नहीं कर रहे हैं, जो ब्लूबर्ड को स्वचालित रूप से देशी वादों में लपेटता है।

@malexdev

यह संकलक के लिए झूठ बोल रहा है, क्योंकि क्नेक्स फ़ंक्शन वास्तव में ब्लूबर्ड लौटाते हैं। रुचि नहीं।
आप सही हैं कि ब्लूबर्ड वादों के अनुकूल हैं, लेकिन टाइपस्क्रिप्ट के साथ सौदे का एक हिस्सा यह है कि आप वास्तव में वही लौटाते हैं जो आप कहते हैं कि आप लौट रहे हैं।

वास्तव में टाइपस्क्रिप्ट के साथ सौदा यह है कि यह पर्याप्त है कि लौटाई गई वस्तु इंटरफ़ेस को सही ढंग से लागू करती है, उदाहरण के लिए यह बिल्कुल ठीक है:

class FakePromise<T> implements Promise<T>  {
    [Symbol.toStringTag]: "Promise";
    then<TResult1, TResult2>(onfulfilled?: (value: T) => TResult1 | PromiseLike<TResult1> | null | undefined, onrejected?: (reason: any) => TResult2 | PromiseLike<TResult2> | null | undefined): Promise<TResult1 | TResult2> {
        return new Promise((resolve, reject) => { resolve('Im totally broken and fake!); });
    }
    catch<TResult>(onrejected?: (reason: any) => TResult | PromiseLike<TResult> | null | undefined): Promise<T | TResult> {
        throw new Error("Method not implemented.");
    }
}

// this works and  fake promise instance has nothing to do with native promise
function returningPromiseInterface(): Promise<string> {
    const fakePromise = new FakePromise<string>();
    return fakePromise;
}

// compiling this fails, because looks like Bluebird actually doesn't implement Promise interface correctly
function asyncReturningPromise(): Promise<string> {
    const blueBirdPromise = new Bluebird<string>((resolve, reject) => { 
        resolve('yay asyncReturningPromise');    
    });
    return blueBirdPromise;
}

यह उदाहरण को गड़बड़ कर देता है, लेकिन टाइपस्क्रिप्ट ने वास्तव में यह भी वादा नहीं किया है कि आपने मूल वादा उदाहरण, केवल इंटरफ़ेस लौटाया है।

वादा वापस करने के लिए टाइप किए गए फ़ंक्शन से ब्लूबर्ड लौटाते समय, टाइपस्क्रिप्ट शिकायत करता है क्योंकि ब्लूबर्ड टाइप प्रॉमिस के समान नहीं है।
ऐसी कई तरकीबें हैं जो हम कर सकते हैं (जैसे कि @ericeslinger ने किसी का उपयोग करने के बारे में क्या उल्लेख किया है, या Promise.resolve() में लपेटकर) लेकिन दिन के अंत में इस तरह की तरकीबें हमें टाइपस्क्रिप्ट द्वारा प्रदान की जाने वाली बहुत कुछ खो देती हैं।

मुझे खराब टाइपिंग को संतुष्ट करने के लिए लोगों को इस तरह की चाल/जेएस कार्यान्वयन बदलने के लिए देखने से नफरत होगी।

दिन के अंत में, वास्तविकता यह है कि अब कम से कम दो उपयोगकर्ता हैं जो कह रहे हैं "मूल वादों का उपयोग करना हमारे लिए महत्वपूर्ण है, और हम वादे की कार्यक्षमता को और अधिक सामान्य बनाने के लिए काम करने को तैयार हैं"।

मुझे एहसास है कि आप सिर्फ मदद करने की कोशिश कर रहे हैं, लेकिन स्पष्ट रूप से सुनने के बजाय "आप इसे इस तरह से कर सकते हैं" मैं यह सुनना चाहता हूं कि क्या मेरे द्वारा प्रस्तावित वादे में बदलाव / @ericeslinger / @ c0b स्वीकार्य हैं ताकि मैं या तो शुरू कर सकूं एक जनसंपर्क पर या क्या।

समझने के लिए धन्यवाद :) देशी वादों का उपयोग करने के लिए knex को बदलना पहले ही शुरू हो गया था और पिछले साल किसी बिंदु पर लागू किया गया था, फिर इसे @tgriesser द्वारा वापस बदल दिया गया था, इसलिए मैं कहूंगा कि अभी के लिए यह बदलाव शुरू नहीं करना बेहतर है।

इसके अलावा, मैं अभी भी इस थ्रेड में उल्लिखित इन टाइपस्क्रिप्ट समस्याओं को टाइपिंग घोषणा में समस्याओं के रूप में मानता हूं (क्यों ब्लूबर्ड प्रॉमिस को सही ढंग से लागू नहीं करता है ... मुझे उस पर और अधिक गहराई से खुदाई करने की आवश्यकता है?), knex कार्यान्वयन में समस्याओं की तुलना में।

कहा जा रहा है, मैं कुछ समय में ब्लूबर्ड से छुटकारा पाने का विरोध नहीं कर रहा हूं, यहां केवल दो अलग-अलग मुद्दों को देख रहा हूं।

:+1: देशी वादों के लिए।

@elhigu :

वास्तव में टाइपस्क्रिप्ट के साथ सौदा यह है कि यह पर्याप्त है कि लौटाई गई वस्तु इंटरफ़ेस को सही ढंग से लागू करती है

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

तो अभी भी देशी वादों के लिए (जो मैं अभी भी मदद करने के लिए तैयार हूं), लेकिन अब मुझे लगता है कि ब्लूबर्ड टाइपिंग को ठीक करके मेरी तत्काल समस्या का समाधान किया जा सकता है। जानकारी के लिए धन्यवाद।

इसलिए मैंने टाइपस्क्रिप्ट का काफी उपयोग करना शुरू कर दिया है और मैं दोनों इसे प्यार करते हैं और अब महसूस करते हैं कि यहां के मुद्दे एक वास्तविक दर्द बिंदु हैं। जैसा कि async/प्रतीक्षा ने हाल ही में नोड भूमि में ब्लूबर्ड उपयोगिता fns ( map , reduce , tap , bind , return ) कम उपयोगी हो जाते हैं। मैं आंतरिक रूप से ब्लूबर्ड का उपयोग जारी रखने के साथ अच्छा होगा लेकिन आधिकारिक तौर पर सभी अतिरिक्त उपयोगिता विधियों को वापस करने वाले knex क्वेरी बिल्डर के सार्वजनिक एपीआई को "बहिष्कृत" कर रहा हूं।

उस विलय के साथ, हम ब्लूबर्ड टाइपिंग ( toBluebird को छोड़कर) को छोड़ने के लिए टाइपस्क्रिप्ट परिभाषाओं को अपग्रेड कर सकते हैं, और ब्लूबर्ड टाइपिंग को प्रॉमिस टाइपिंग में बदल सकते हैं।

अगर किसी के पास बैंडविड्थ है तो वह इससे निपटना चाहता है, यहां मैं कार्य योजना के बारे में सोच रहा हूं:

• [ ] सभी ब्लूबर्ड प्रॉक्सी विधियों ( tap , map , reduce , bind , return ) के लिए एक बहिष्करण चेतावनी जोड़ें।
• [ ] एक .toBluebird() विधि जोड़ें जो उन लोगों के लिए एक माइग्रेशन पथ होगा जो ब्लूबर्ड का उपयोग जारी रखना चाहते हैं (वे उपरोक्त विधियों की सभी कॉलों की एक साधारण खोज/प्रतिस्थापन के साथ ऐसा कर सकते हैं और इसे पहले जोड़ सकते हैं जिन्हें कहा जाता है)
• [ ] एक बार यह विलय/नई रिलीज कट (0.15) हो जाने के बाद हम टाइपस्क्रिप्ट परिभाषाओं को अपडेट कर सकते हैं
• [ ] आखिरकार हम इन तरीकों को पूरी तरह से छोड़ सकते हैं। यह सरल एपीआई अंततः मूल वादे और एसिंक/प्रतीक्षा का उपयोग करने का मार्ग प्रशस्त करता है जब यह समझ में आता है।

मुझे बताएं कि क्या यह समझ में आता है और अगर किसी को इस पर शॉट लेने में दिलचस्पी है।

निश्चित रूप से इसमें मदद करने में दिलचस्पी होगी।

क्या इसका मतलब यह है कि Knex अपनी टाइपस्क्रिप्ट परिभाषाओं को बनाए रखना शुरू कर देगा? हमें जेनेरिक के साथ कुछ अच्छी चीजें करने की अनुमति देगा जो ऑटोजेनरेटेड टाइपिंग कभी भी समर्थन नहीं करेगा।

मैंने इस कांटे को देशी वादों के लिए समर्थन जोड़ने के पहले प्रयास के रूप में शुरू किया:
https://github.com/tgriesser/knex/pull/2523/files

2016 की इस टिप्पणी को पसंद करें:

जिज्ञासु: आप एक तेज़ लाइब्रेरी को धीमे अंतर्निर्मित से बदलना चाहते हैं

कमाल है 2 साल में कितना कुछ बदल सकता है।

वादा वापस करने के लिए टाइप किए गए फ़ंक्शन से ब्लूबर्ड लौटाते समय, टाइपस्क्रिप्ट शिकायत करता है क्योंकि ब्लूबर्ड टाइप प्रॉमिस के समान नहीं है।

@malexdev वास्तव में टाइपस्क्रिप्ट संरचनात्मक टाइपिंग का उपयोग करता है (प्रवाह नाममात्र टाइपिंग का उपयोग करता है और आपके द्वारा वर्णित तरीके से काम करेगा) इसलिए जब तक आपका प्रकार Promise इंटरफ़ेस को पूरा करता है यह Promise के साथ संगत है चाहे वह स्पष्ट रूप से extends हो implements यह या नहीं।

यह कैसे आगे बढ़ रहा है? मुझे लगता है कि एक अच्छा पहला कदम ब्लूबर्ड विशिष्ट विधि कॉल को नेक्स के भीतर कारक बनाना होगा (यानी वास्तव में इसे अभी तक हटाएं नहीं)। ब्लूबर्ड को हटाना और कस्टम प्रॉमिस कंस्ट्रक्टर के लिए एक विकल्प प्रदान करना अनुसरण करेगा (और ब्लूबर्ड विधियों का उपयोग करने वाले लोगों को एक अपग्रेड पथ दें)।

कोई आपत्ति न होने पर मैं पहले चरण पर काम शुरू नहीं कर रहा हूं। ऐसा लगता है कि मौजूदा काम मर गया है।

@qubyte मुझे नहीं लगता कि परिवर्तन करने के लिए कोई सक्रिय प्रयास है, वृद्धिशील परिवर्तन यहाँ और वहाँ किए गए थे, लेकिन यह इसके बारे में है।

ठीक। अपने खाली समय के अगले भाग में मैं प्रत्येक विधि को अलग-अलग करने के लिए कुछ छोटे-से-संभव परिवर्तन करूँगा।

@tgriesser कोई राय जब हमें इसके साथ आगे बढ़ना चाहिए (यदि कभी)? मेरे लिए अगला अप्रैल इसके लिए एक उचित समय की तरह लगेगा जब नोड 6 एलटीएस लाइन के अंत तक पहुंच जाएगा।

2018 में दिलचस्प जानकारी:

नोड 10 में promises-native-async-await का प्रदर्शन promises-bluebird से बेहतर है।
संदर्भ: https://github.com/petkaantonov/bluebird/tree/master/benchmark

इसलिए प्रदर्शन अब ब्लूबर्ड रखने का कारण नहीं है। हमें एसिंक/प्रतीक्षा के लिए जाना चाहिए।

वादे-मूल-async-प्रतीक्षा का बेहतर प्रदर्शन है

2016 में मेरा भी यही दृढ़ विश्वास था कि मूल तरीके में बहुत तेजी से सुधार होगा, सिर्फ इसलिए कि यह Nodejs समुदाय का मूल है, इसकी देखभाल करने वाले लोगों की संख्या अधिक है, किसी भी तीसरे पक्ष के पुस्तकालयों से अधिक

जबकि, विकल्प के लिए टिकट दायर किया गया था, बहुत सारे प्रतिस्पर्धी Promise कार्यान्वयन हैं, ब्लूबर्ड पर हमेशा के लिए दांव लगाना अच्छा नहीं है

क्या इस पर कोई अपडेट है?

@cfanoulis वही अभी भी खड़ा है। जब अप्रैल आता है, हम नोड 6 के लिए समर्थन छोड़ सकते हैं और ब्लूबर्ड को हटाना शुरू कर सकते हैं।

कोई 2019 अपडेट? /cc कुछ मुख्य योगदानकर्ताओं या अनुरक्षकों या किसी को भी @here जो इसकी परवाह करता है: @johanneslumpe @tgriesser @wubzz @elhigu https://github.com/tgriesser/knex/graphs/contributors?type=c&from=2018-01 से-

दूसरी ओर, जावास्क्रिप्ट समुदाय एक ऐसी गतिशील, जीवंत और कभी-कभी क्रूर दुनिया है, हर 3 या 2 साल (या इससे भी तेज) कुछ ऐसी चीज़ों के लिए प्रतिस्थापन होते हैं जिनसे हम पहले परिचित थे, ग्रंट के बारे में सोचें, गल्प => वेबपैक, उपकरण, पुस्तकालयों, ढांचे हर स्तर पर पूरी तरह से प्रतिस्पर्धा कर रहे हैं, इसलिए, पुराने पुस्तकालयों के लिए यदि आप नवाचारों को लाना बंद कर रहे हैं, या नए मानकों का समर्थन धीमा कर रहे हैं (ES2019 async/प्रतीक्षा इटरेटर के बारे में सोचें ...)

मैंने अभी कुछ सरल शोध किया है, ऐसा लगता है कि डीबी ओआरएम स्तर पर भी कई विकल्प हैं, टाइपओआरएम एक अच्छा हो सकता है ... (मैं यहां और अधिक नहीं कहने के लिए रुकता हूं ...)
https://bestofjs.org/tags/db
https://bestofjs.org/projects/typeorm

@ c0b को cc करने की कोई आवश्यकता नहीं है। मुझे वैसे भी सभी टिप्पणियों से मेल मिलते हैं। @kibertoad ने अपनी आखिरी टिप्पणी में जो कुछ कहा था, वह सिर्फ इतना ही कहा ... इस मुद्दे का भी knex से कोई लेना-देना नहीं है जो async का समर्थन करता है / ES2019 की बेहतर सुविधाओं का इंतजार करता है और knex एक ORM नहीं है, इसलिए मुझे यकीन नहीं है कि वह टिप्पणी वास्तव में क्या थी के बारे में।

यदि आपको एक अच्छे ओआरएम की आवश्यकता है, तो मैं आपत्ति की सिफारिश कर सकता हूं। जेएस। इसे knex के शीर्ष पर भी लागू किया गया है, यहाँ इसके बारे में बहुत अच्छा सूत्र है https://github.com/Vincit/objection.js/issues/1069

किसी बिंदु पर इस knex को बदल दिया जाएगा, लेकिन किसी ORM के साथ नहीं। इसे किसी अन्य क्वेरी बिल्डर द्वारा प्रतिस्थापित किया जा सकता है, जिसमें क्लीनर कोड बेस और अधिक सुसंगत एपीआई है। उदाहरण के लिए knex 1.0 शायद;)

इसके अलावा अगर knex को बदल दिया जाता है तो मैं उसके साथ पूरी तरह से ठीक हो जाऊंगा, मेरे लिए कम काम: D

उस पर डब्ल्यूआईपी है जो मुझे विश्वास है: https://github.com/tgriesser/knex-next

बस यह भी उल्लेख करना चाहता था कि मूल वादों का उपयोग नहीं करने के परिणामस्वरूप https://github.com/nodejs/node/issues/22360 में async_hooks का उपयोग करते समय वर्तमान संदर्भ खो जाता है।

मेरा विश्वास करो, हमें स्थानांतरित करने के लिए अतिरिक्त कारणों की आवश्यकता नहीं है, हम इसे उतना ही बुरा करना चाहते हैं जितना आप सभी करते हैं :)। हालांकि, हमें अभी भी नोड 6 शाखा में कुछ और सुधार जारी करने की आवश्यकता है, और फिर (आखिरकार), हम इसे छोड़ देंगे और धीरे-धीरे ब्लूबर्ड को चरणबद्ध करना शुरू कर देंगे।

#3227 के विलय के बाद, हम अंत में आरंभ कर सकते हैं!

मुझे पता है कि आपने पहले उल्लेख किया था कि आप इस प्रवास में मदद का उपयोग कर सकते हैं, यदि आप अभी भी उस दिशा में जाना चाहते हैं, तो क्या हम किसी भी तरह से मदद कर सकते हैं?

मैं सोच रहा हूं: एक प्रोजेक्ट बनाएं, कुछ कार्य जोड़ें, और देखें कि क्या कोई (शायद मेरे पास समय है) असाइन किया जा सकता है और कुछ तिथियां निर्धारित कर सकता है?

@chaffeqa जल्द ही कुछ और बारीक कार्य तैयार करेगा, आसान परिवर्तनों के पहले दौर के लिए #3250 अप करें। मुख्य रूप से हमें कुछ देशी-आधारित के साथ bluebird.tap, bluebird.method और bluebird.try उपयोगों को प्रतिस्थापित करने की आवश्यकता है। यदि आपके पास पहले से कुछ समय है, तो आप #3250 से शाखा लगाने की कोशिश कर सकते हैं और किसी भी शेष 'ब्लूबर्ड' की आवश्यकता पर एक नज़र डाल सकते हैं (मैं गैर-बोली-विशिष्ट लोगों के साथ शुरू करने की सलाह दूंगा ताकि आप test:sqlite चलाकर अभी भी काम कर रहे कार्यक्षमता को जल्दी से मान्य कर सकें।

@qubyte यदि आप योगदान देना चाहते हैं, तो अब समय आ गया है!

@kibertoad क्या मैं अब async/प्रतीक्षा का उपयोग करने के लिए सुरक्षित हूं?

आपका मतलब knex कोडबेस में है? ज़रूर। अपनों में तुम हमेशा थे :-D

https://github.com/tgriesser/knex/issues/3253
https://github.com/tgriesser/knex/issues/3254
https://github.com/tgriesser/knex/issues/3255
https://github.com/tgriesser/knex/issues/3256
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgriesser/knex/issues/3268
https://github.com/tgriesser/knex/issues/3286
हथियाने के लिए हैं।

पिछले हफ्ते एमआईए होने के लिए खेद है, हमारी कंपनी के लिए चीजें बढ़ रही हैं इसलिए मुझे वहां ध्यान केंद्रित करना पड़ रहा है।

अपग्रेड के लिए बड़े ब्लॉकों में से एक पर हमारे द्वारा की गई कुछ चर्चाओं पर लूप को बंद करना चाहता था: Disposer उपयोग की जगह।

जब आप इसे नीचे जाना शुरू करते हैं तो यह बहुत गहरा होता है, इसलिए एक अच्छी कॉपी/एब्स्ट्रैक्शन प्रदान करने के लिए कुछ अच्छी इंजीनियरिंग लेनी होगी। मुझे चिंता है कि किसी चीज़ का पूर्ण ओवरहेड बहुत बड़ा हो सकता है (वादा श्रृंखला बढ़ने के साथ ही बहुत अधिक वस्तुएं बनाई जाती हैं)।

मैंने वास्तव में कुछ पीओसी पर शुरू किया था, और मुझे लगता है कि यह उनमें से सबसे सीधा है:

class DisposablePromise extends Promise {

  disposerFunc = null;
  originalResource = null;

  then(onFulfilled, onRejected) {
    const $onFulfilled = this.wrap(onFulfilled);
    return super.then($onFulfilled, onRejected).copyContext(this);
  }

  copyContext(promise) {
    this.disposerFunc = promise.disposerFunc;
    this.originalResource = promise.originalResource;
    return this;
  }

  disposer(disposerFunc) {
    this.disposerFunc = disposerFunc
  }

  isDisposable() {
    return !!this.disposerFunc
  }

  wrap(onFulfilled: any) {
    const $onFulfilled = (result: any) => {
      if (this.disposerFunc && !this.originalResource) {
        this.originalResource = result
      }
      if (result instanceof Promise) {
        return onFulfilled(result);
      } else {
        const res = onFulfilled(result)
        if (this.disposerFunc) {
          this.disposerFunc(this.originalResource)
        }
        return res
      }
    };

    return $onFulfilled;
  }
}

और दुसरी:

      var DisposablePromise = function DisposablePromise() {
          var self = DisposablePromise.convert(Promise.resolve());
          return self;
      };
      DisposablePromise.convert = function convert(promise, props) {
          promise.__proto__ = DisposablePromise.prototype;
          return props ? Object.assign(promise, props) : promise;
      };
      DisposablePromise.prototype = Object.create(Promise.prototype);
      DisposablePromise.prototype.constructor = DisposablePromise;
      DisposablePromise.prototype.then = function then(resolve, reject) {
          var returnVal = Promise.prototype.then.call(this, resolve, reject);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.catch = function _catch(err) {
          var returnVal = Promise.prototype.catch.call(this, err);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.finally = function finall(obj) {
          var returnVal = Promise.prototype.finally.call(this, obj);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.disposer = function disposer(disposerFunc) {
        var returnVal = Promise.prototype.finally.call(this, obj);
        return DisposablePromise.convert(returnVal);
      };

लेकिन उन्हें साबित करने का समय नहीं मिला।

मुझे लगता है कि यह वास्तव में अन्य विकल्पों का पता लगाने के लिए सार्थक हो सकता है (ब्लूबर्ड रखें लेकिन इसे आंतरिक रूप से देशी वादों का उपयोग करने के लिए परिवर्तित करें?) इस तथ्य के कारण कि यह सुविधा भंडार में होनी चाहिए (जब तक कि आप बेहतर दृष्टिकोणों के बारे में नहीं सोच सकते ... उस कार्यक्षमता को अमूर्त करने पर भी ब्लूबर्ड टीम द्वारा किसी भी विचार को सुनना अच्छा लगेगा, हालांकि मेरी आंत कहती है कि यह ब्लूबर्ड कार्यान्वयन हुक से काफी जुड़ा हुआ है।

मैं कहूंगा कि अगर हम इस हिस्से को समझ सकते हैं, तो बाकी के काम बहुत सीधे आगे हैं।

@chaffeqa Np, सराहना करते हैं कि आपको अभी भी इस पर वापस आने का समय मिल रहा है!
मुझे अत्यधिक संदेह है कि ब्लूबर्ड लोग अपने कार्यान्वयन को गंभीरता से पुन: पेश करने के सुझावों के लिए खुले होंगे, उन्होंने बार-बार इस बात को दोहराया है कि इस बिंदु पर वे हर चीज से ऊपर स्थिरता में रुचि रखते हैं, और वे लोगों को वास्तव में मूल वादों का उपयोग करने की सलाह देते हैं जब तक कि किसी को वास्तव में उन्नत सुविधाओं की आवश्यकता न हो ब्लूबर्ड द्वारा प्रदान किया गया।
यह देखते हुए कि Node 8 अभी Node.js का सबसे लोकप्रिय संस्करण प्रतीत होता है (आधिकारिक Node.js डाउनलोड आंकड़ों के आधार पर), मुझे डर है कि हम अभी तक async iterator-आधारित दृष्टिकोण पर नहीं जा सकते हैं।
आंतरिक रूप से DisposablePromise को लागू करने वाले Knex में आप क्या कमियां देखते हैं? चूंकि यह मूल वादा बढ़ाता है, मुझे लगता है कि यह इसके साथ ब्लूबर्ड कमियों में से कोई भी नहीं लाता है, और उपयोगकर्ता स्पेस में कुछ भी इसके बारे में जानने की जरूरत नहीं है?

@ericeslinger FWIW, TS टाइपिंग में अब मास्टर में कोई समस्या नहीं होनी चाहिए, हम उपयोगकर्ताओं को ब्लूबर्ड सुविधाओं पर भरोसा करने से हतोत्साहित करने के लिए अपने वादों को अब मूल के रूप में टाइप कर रहे हैं। यह सड़क के नीचे मुद्दों का कारण बन सकता है जब देशी वादे कुछ ऐसा लागू करते हैं जो ब्लूबर्ड वादे नहीं करते हैं, इसलिए हम अभी भी जितना संभव हो उतना इस्तेमाल किए गए वादों को बदलना चाहते हैं। इन पंक्तियों के साथ किसी भी योगदान की बहुत सराहना की जाएगी :)

मेवा मुझे उतना ही लगा
मैं सहमत हूं कि DisposablePromise जैसा कुछ करना शायद इस मामले में जाने का तरीका है, खासकर जब से वास्तव में जिस वस्तु की आवश्यकता है वह अभी भी प्रस्ताव में है।

नकारात्मक पक्ष यह है कि एक विवेकपूर्ण तरीके से DisposablePromise जैसे कुछ इंजीनियर करना बहुत महत्वपूर्ण होगा ... और स्पष्ट रूप से मुझे यह भी नहीं पता कि मेरा कार्यान्वयन काम करता है (मुझे किसी कारण से एसिंक सोचने में बहुत परेशानी है हा)।

अगर इस धागे पर कोई और है जो इस मुद्दे पर एक स्टैब लेना चाहता है <3 यू लॉन्गटाइम्स!

@chaffeqa ब्लूबर्ड कार्यान्वयन कितना जटिल है? हो सकता है कि हम इसे आसानी से निकाल सकें और मूल वादे के शीर्ष पर जोड़ सकें?

@chaffeqa सबसे खराब स्थिति - हम अन्य सभी ब्लूबर्ड उपयोगों को हटा सकते हैं और इसे इसकी जटिलता के कारण रख सकते हैं यदि हम इसे छूने के लिए बहुत जोखिम भरा मानते हैं। आदर्श नहीं है, लेकिन अंततः using होने जा रहा है।

दुर्भाग्य से बहुत जटिल ... कार्यान्वयन इस तथ्य पर निर्भर करता है कि ब्लूबर्ड वादा जीवनचक्र को नियंत्रित करता है। मुझे लगता है कि सबसे अच्छा तरीका यह देखना है कि वह क्या करने की कोशिश कर रहा है (जो ऊपर using पर लिंक के बहुत करीब है) और इसके लिए जितना संभव हो उतना सरल और प्रदर्शन करने वाला शिम बनाएं।

समस्या यह है कि पाइपलाइन एक Bluebird शैली का वादा होना चाहिए, जिसे अगर मैं सही ढंग से समझता हूं, तो मूल वादे के प्रदर्शन का पालन नहीं करता है (और इसलिए आप सभी ट्रेसिंग + देशी एसिंक कार्यक्षमता खो देते हैं)।

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

FYI करें मेरे दिमाग में एक और बात है: वास्तव में knex में usage और .disposer का न्यूनतम उपयोग होता है, इसलिए हो सकता है कि दृष्टिकोण इसे उच्च स्तर पर ले जाने के लिए बेहतर काम करे?

एक प्रयोग के लायक :)

oooo भी एक विकल्प है जो मुझे https://github.com/petkaantonov/bluebird/issues/1593 पर आधारित मिला है

किसी भी तरह से, मुझे लगता है कि एक अच्छा कदम आगे था जो आपने पिछली शाखा पर शुरू किया था, जहां हम सभी Promise उपयोग को अलग करते हैं जो वास्तव में BluebirdPromise है, इस तरह हम ड्रॉपिंग के साथ खेलना शुरू कर सकते हैं DisposablePromise या BluebirdNativePromise जैसे प्रतिस्थापन में।

@chaffeqa आपका मतलब Bluebird.setScheduler(fn => Promise.resolve().then(fn)) हिस्सा है?
कुल मिलाकर रूपांतरण वास्तव में सुचारू रूप से आगे बढ़ रहा है! यदि हम मूल वादों का उपयोग करते हुए ब्लूबर्ड में डिस्पोजल रख सकते हैं, तो यह वास्तव में एक अच्छा समाधान हो सकता है।

ठीक है, तो इन पर अभी भी ध्यान देने की ज़रूरत है:
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgriesser/knex/issues/3286
https://github.com/tgriesser/knex/issues/3256

मदद की सबसे अधिक सराहना की जाएगी!

बस यह भी उल्लेख करना चाहता था कि async_hooks का उपयोग करते समय मूल वादों का उपयोग नहीं करने से नोडज/नोड # 22360 में परिणाम होता है जो वर्तमान संदर्भ को खो देता है।

समाधान https://github.com/TimBeyer/cls-bluebird पैच का उपयोग करना है।

केवल जानकारी के लिए, Node v8 के लिए LTS इस वर्ष समाप्त हो रहा है।

@ बेसोनोव संदर्भ? 10 से 10 तक टकराने से यह समस्या कैसे प्रभावित होती है? ध्यान दें कि हमने नोड 6 समर्थन पहले ही छोड़ दिया है।

मैं knex कोड आधार से परिचित नहीं हूं, लेकिन हो सकता है कि कुछ विशेषताएं हों, जो आपको ब्लूबर्ड को दूर करने में मदद कर सकती हैं। उदाहरण के लिए, नोड 10 में Promise.finally का समर्थन है।

लेकिन वैसे भी, मुझे इस विषय पर प्रगति देखकर खुशी हुई: +1:

डिस्पोजर पैटर्न के बारे में - क्या हम सिर्फ चीजों के लिए वैकल्पिक कॉलबैक जोड़ सकते हैं, जो डिस्पोजेबल वादा लौटाते हैं?
(जैसे लेनदेन के साथ)

getDisposableConnection(config, cb) {
    const connection = await getConnection(config)

   // user want autodisposable connection
    if (cb) 
      Promise.resolve(cb(connection)).then(() => connection.dispose())
   // user will dispose by himself
   return connection
}

हमें किस स्तर की पुस्तकालय स्वतंत्रता की आवश्यकता है?
1) सभी देशी वादों का प्रयोग करें
2) आंतरिक मूल वादे, उपयोगकर्ता इंटरफ़ेस के लिए अपना वादा lib सेट कर सकते हैं
3) उपयोगकर्ता आंतरिक और इंटरफ़ेस के लिए वादा lib सेट कर सकता है

इस मुद्दे की वर्तमान स्थिति क्या है। आम तौर पर knex अब async प्रतीक्षा के साथ काम करता है लेकिन टाइपस्क्रिप्ट चेतावनी की रिपोर्ट करेगा कि हम उस विधि की प्रतीक्षा कर रहे हैं जो मूल वादा नहीं है।

तो मूल मुद्दे के प्रश्न का उत्तर देने के लिए। वर्तमान समाधान बस प्रतीक्षा करना और // tslint:disable-next-line: await-promise जैसा कुछ जोड़ना है

@maximelkin मैं विकल्प 1 के लिए वोट करता हूं। लंबी अवधि में मुझे उम्मीद है कि हर वादा पुस्तकालय अप्रचलित हो जाएगा।

दूसरी बात, इस बिंदु पर हम अधिकांश ब्राउज़रों के लिए भी पॉलीफ़िल के वादे से परे हैं

@Bessonov वर्तमान में knex पर पुस्तकालयों (और शायद परियोजनाओं) पर निर्भर करता है, जिसके लिए बिल्कुल ब्लूबर्ड की आवश्यकता होती है

हमें उनके लिए कुछ कमबैक समाधान देना चाहिए

@Bessonov वर्तमान में knex पर पुस्तकालयों (और शायद परियोजनाओं) पर निर्भर करता है, जिसके लिए बिल्कुल ब्लूबर्ड की आवश्यकता होती है, हमें उनके लिए कुछ फ़ॉलबैक समाधान देना चाहिए

इससे कोई फर्क नहीं पड़ता कि क्नेक्स के उपयोगकर्ता ब्लूबर्ड पर निर्भर हैं या नहीं। Knex अभी भी मूल वादों का उपयोग कर सकता है और वे ब्लूबर्ड वादों के साथ ठीक से काम करेंगे। हमें बिल्कुल भी कमियां नहीं देनी चाहिए।

तो यह मुद्दा वादा कार्यान्वयन चुनने के साथ फीचर के अनुरोध के साथ शुरू हुआ।
कहीं से भी, यह बिना किसी कारण के ब्लूबर्ड को हटाने और सभी आश्रितों को तोड़ने में बदल गया। बिना किसी चेतावनी के, चैंज, फ़ॉलबैक और प्रमुख रिलीज़ के लिए विकल्प।

लेकिन मुझे लगता है कि सभी 1.5 टाइपस्क्रिप्ट उपयोगकर्ता अब खुश हैं।

तो यह मुद्दा वादा कार्यान्वयन चुनने के साथ फीचर के अनुरोध के साथ शुरू हुआ।
कहीं से भी, यह बिना किसी कारण के ब्लूबर्ड को हटाने और सभी आश्रितों को तोड़ने में बदल गया। बिना किसी चेतावनी के, चैंज, फ़ॉलबैक और प्रमुख रिलीज़ के लिए विकल्प।

कम से कम पहले knex 0.x संस्करणों के साथ संभावित ब्रेकिंग परिवर्तनों के साथ प्रमुख रिलीज़ के रूप में माना जाता है, इसलिए केवल 0.20.x को अपडेट करना सुरक्षित अपग्रेड माना जाना चाहिए था (संस्करण संख्या <1 होने पर सेवर वास्तव में ढीला है)।

ब्लूबर्ड को हटाना लंबे समय से टेबल पर है, यह केवल इस मुद्दे के बारे में नहीं है।

बिना किसी कारण के ब्लूबर्ड को हटाना

ब्लूबर्ड को हटाना अकारण नहीं रहा है। आप अभी भी बाहरी रूप से ब्लूबर्ड का उपयोग knex वादों के साथ कर सकते हैं। ब्लूबर्ड को छोड़ने का एक बड़ा कारण यह है कि async फ़ंक्शंस निहित रूप से मूल वादे बनाता है, इसलिए भविष्य में ब्लूबर्ड का उपयोग करते रहने के लिए बिना किसी कारण के अतिरिक्त ब्लूबर्ड रैपिंग कोड को knex API में जोड़ने की आवश्यकता होगी।

बिना किसी चेतावनी के, चैंज,

माना। मैंने नवीनतम चैंजों को देखा... दुख की बात है कि ऐसा लगता है कि हम संस्करणों के बीच ब्रेकिंग परिवर्तनों को सूचीबद्ध करने में विफल रहे हैं। पुराने एपीआई को तोड़ने वाले परिवर्तनों को वास्तव में इंगित करने के लिए हमें चेंजलॉग लिखते समय अधिक सावधान रहने की आवश्यकता है। उदाहरण के लिए, कई टाइपिंग परिवर्तन वास्तव में पुराने TS कोड को तोड़ देंगे।

Ioredis प्रोजेक्ट https://github.com/luin/ioredis/commit/da60b8b पर भी यही समस्या थी। वे मूल वादों का समर्थन करना चाहते थे - और लोगों ने वास्तव में एक अच्छा समाधान बनाया - उन्होंने किसी भी कस्टम वादा पुस्तकालय का समर्थन करने के लिए एक विकल्प जोड़ा और वे डिफ़ॉल्ट रूप से मूल वादे का उपयोग करते हैं। क्यों नहीं? एक कस्टम वादा पुस्तकालय सेट करना तेज़ है और सभी एप्लिकेशन कोड को पैच करने की आवश्यकता नहीं है।

ब्लूबर्ड का उपयोग करते रहने के लिए अतिरिक्त ब्लूबर्ड रैपिंग कोड की आवश्यकता होती है जो बिना किसी कारण के knex API में जोड़ा जाना चाहिए।

हाँ। लेकिन ब्लूबर्ड (या किसी अन्य वादा पुस्तकालय) में मॉड्यूल कॉल क्यों नहीं लपेटते हैं यदि यह स्पष्ट रूप से निर्दिष्ट किया गया था? यह एक साधारण आवरण है, शून्य ओवरहेड, और यह उपयोगकर्ताओं को जो भी वादा पुस्तकालय चाहता है उसका उपयोग करने की अनुमति देगा। यदि किसी को ब्लूबर्ड की आवश्यकता नहीं है, तो कोई भी इस विकल्प का उपयोग नहीं करेगा, और आप इसे समय पर सुरक्षित रूप से हटा सकते हैं।

साथ ही, मैंने एक राय देखी कि

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

लेकिन आईएमएचओ दो गलत धारणाएं हैं:

• ब्लूबर्ड का उपयोग किया जाता है क्योंकि यह तेज़ है।
• ब्लूबर्ड का उपयोग पोलीफिल के रूप में किया जाता है।

मुझे लगता है कि वास्तव में जटिल अनुप्रयोगों के मामले में ऐसा नहीं है, जो एसिंक-प्रतीक्षा एक लाइनर से परे जाते हैं।
ब्लूबर्ड में कई विशेषताएं हैं जो जटिल एसिंक प्रवाह के लिए बिल्कुल जरूरी हैं - जैसे टाइमआउट, कस्टम त्रुटि प्रबंधन, समेकन के साथ मैपिंग, रद्दीकरण, कम करना आदि। उन सभी सुविधाओं को मूल वादों में लागू किया जा सकता है, लेकिन यह बहुत बेकार बॉयलरप्लेट है। 2020 में, हम अभी भी नोड 12 में ब्लूबर्ड का उपयोग कर रहे हैं क्योंकि हम यह सब बॉयलरप्लेट नहीं चाहते हैं।

क्यों नहीं? एक कस्टम वादा पुस्तकालय सेट करना तेज़ है और सभी एप्लिकेशन कोड को पैच करने की आवश्यकता नहीं है।

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

@qubyte

यह उतना छोटा उपक्रम नहीं है जितना कि यह पहले निरीक्षण में लग सकता है।

नहीं, यह उतना ही सरल है जितना मैं पहले ही बता चुका हूँ। आप निर्यात किए गए बाहरी कार्यों के लिए एक आवरण बनाते हैं और बस इतना ही। कोड की लगभग 10 पंक्तियाँ। और सभी आंतरिक कोड को किसी भी तरह से लिखें।

@jehy : कोड की उन 10 पंक्तियों के लिए एक पीआर जमा करने के लिए स्वतंत्र महसूस करें यदि आप उन्हें लागू करने का एक सीधा तरीका देखते हैं।

मैं आज कुछ समय डब्ल्यू/वर्क-अराउंड आने की कोशिश में भी बिताऊंगा।

इसके लायक क्या है, ब्लूबर्ड के अधिकांश एपीआई को इन पैकेजों द्वारा मूल वादों का उपयोग करके समान या करीबी एपीआई के साथ डुप्लिकेट किया गया है: https://github.com/sindresorhus/promise-fun

इसके लायक क्या है, ब्लूबर्ड के अधिकांश एपीआई को इन पैकेजों द्वारा मूल वादों का उपयोग करके समान या करीबी एपीआई के साथ डुप्लिकेट किया गया है

~ 1 के बजाय 50 पैकेज? गंभीरता से?

हां, हालांकि ज्यादातर समय केवल कुछ की आवश्यकता होती है (उदाहरण के लिए पी-मैप)। सचमुच में, आपका माइलेज अलग अलग हो सकता है। इसे आप जो चाहते हैं उसके लिए केवल एक संभावित मार्ग के रूप में पेश किया जाता है।

@jehy : यहां कुछ ऐसा है जिसे आप अपने आवेदन कोड के भीतर अस्थायी कामकाज के रूप में आजमा सकते हैं:

const Bluebird = require('bluebird');


const prototypesNeedingDecoration = [
  require('knex/lib/query/builder').prototype,
  require('knex/lib/schema/builder').prototype,
  require('knex/lib/transaction').prototype,
  require('knex/lib/raw').prototype,
];

const corePromiseMethods = ["then", "catch", "finally"];


function decoratePromiseMethods(target) {
  for(const m of corePromiseMethods) {
    const original = target[m];

    target[m] = function(...args) {
      return Bluebird.resolve(original.apply(this, args))
    }
  }  
}

function hackBluebird() {
  for(const target of prototypesNeedingDecoration) {
    decoratePromiseMethods(target);
  }
}


hackBluebird();

यह वास्तव में समग्र समस्या का पर्याप्त समाधान नहीं है। knex के भीतर बनाई गई अन्य अस्थायी वस्तुएं हैं जिन्हें समान तरीके से सजाने की आवश्यकता होगी।

इसके अलावा, अस्वीकरण: वर्कअराउंड ️ का बहुत कम परीक्षण हुआ है। इसलिए, आपको यह सुनिश्चित करने के लिए अपने आवेदन के परीक्षणों को फिर से चलाना चाहिए कि कुछ भी तोड़ा नहीं गया है।

बस अपने 2 सेंट यहां जोड़ना चाहता था: नकारात्मक प्रतिक्रिया की परवाह किए बिना, मैं वास्तव में इस माइग्रेशन में किए गए सभी कार्यों की सराहना करता हूं।

हमारे ऐप के दृष्टिकोण से, knex आखिरी लाइब्रेरी थी जिसने हमें ब्लूबर्ड की आवश्यकता के लिए मजबूर किया, और पूर्ण मूल वादा समर्थन के अनुरूप होने का मतलब है कि:

1. हमारे पास अब दूषित स्टैक निशान नहीं हैं
2. हमने अपने SSR वजन को एक अच्छी मात्रा में कम किया
3. हमने सुधार किया है क्योंकि देशी एसिंक प्रतीक्षा अब ब्लूबर्ड की तुलना में अधिक प्रदर्शनकारी है (और अधिक से अधिक बढ़ रहा है!)

यह es मानक की ओर दौड़ना जारी रखने के लिए इतनी बड़ी जीत है ... और मुझे पता है कि पुस्तकालय अनुरक्षकों के लिए यह आसान नहीं है इसलिए मैं आप लोगों को चिल्लाना चाहता था और इस तरह के बोझ को उठाने के लिए धन्यवाद!

परिवर्तन से पीड़ित लोगों के लिए: मुझे मदद करना अच्छा लगेगा क्योंकि हमें लाभ हुआ है, इसलिए यदि आपको डिबगिंग या माइग्रेट करने में सहायता चाहिए तो कृपया संपर्क करें!

@chaffeqa इस प्रतिक्रिया के लिए धन्यवाद, यह बहुत मायने रखता है!

@ जेही : क्या आपको प्रस्तावित काम करने की कोशिश करने का मौका मिला है? यदि हां, तो क्या इससे आपकी तात्कालिक समस्याओं का समाधान हुआ?