यदि आप yield_per . के साथ उनका उपयोग करने का प्रयास करते हैं, तो दोनों समस्याग्रस्त लोडिंग रणनीतियाँ अपवाद उत्पन्न करती हैं , इसलिए आपको वास्तव में बहुत अधिक चिंता करने की आवश्यकता नहीं है।
मैं विश्वास करता हूं सबक्वेरीलोड . के साथ एकमात्र समस्या यह है कि दूसरी क्वेरी की बैच लोडिंग लागू नहीं की गई है (अभी तक)। अर्थ की दृष्टि से कुछ भी गलत नहीं होगा, लेकिन यदि आप yield_per . का उपयोग कर रहे हैं , संभवतः आपके पास सभी परिणामों को एक साथ लोड न करने का वास्तव में एक अच्छा कारण है। तो SQLAlchemy विनम्रतापूर्वक आपकी इच्छा के विरुद्ध जाने से इंकार कर देता है।
शामिल हो गया थोड़ा अधिक सूक्ष्म है। यह केवल संग्रह के मामले में प्रतिबंधित है, जहां प्राथमिक पंक्ति में एकाधिक संबद्ध पंक्तियां हो सकती हैं। मान लें कि आपकी क्वेरी इस तरह कच्चे परिणाम उत्पन्न करती है, जहां ए और बी विभिन्न तालिकाओं से प्राथमिक कुंजी हैं:
A | B
---+---
1 | 1
1 | 2
1 | 3
1 | 4
2 | 5
2 | 6
अब आप इन्हें yield_per(3) . के साथ लाएं . समस्या यह है कि SQLAlchemy केवल पंक्तियों . द्वारा प्राप्त होने वाली मात्रा को सीमित कर सकता है , लेकिन उसे वस्तुओं . को वापस करना होगा . यहाँ, SQLAlchemy केवल पहली तीन पंक्तियों को देखता है, इसलिए यह एक A बनाता है कुंजी 1 और तीन . के साथ ऑब्जेक्ट बी बच्चे:1, 2, और 3.
जब यह अगले बैच को लोड करता है, तो यह एक नया A बनाना चाहता है ऑब्जेक्ट कुंजी 1... आह के साथ, लेकिन इसमें पहले से ही उनमें से एक है, इसलिए इसे फिर से बनाने की कोई आवश्यकता नहीं है। अतिरिक्त बी , 4, खो गया है। (इसलिए, नहीं, यहां तक कि yield_per . के साथ जुड़े हुए संग्रहों को पढ़ना भी असुरक्षित है — आपके डेटा का कुछ हिस्सा गायब हो सकता है।)
आप कह सकते हैं "ठीक है, बस पंक्तियों को तब तक पढ़ते रहें जब तक आपके पास एक पूर्ण वस्तु न हो" - लेकिन क्या होगा यदि वह A सौ बच्चे हैं? या एक लाख? SQLAlchemy उचित रूप से गारंटी नहीं दे सकता है कि यह वही कर सकता है जो आपने पूछा था और सही परिणाम देता है, इसलिए यह कोशिश करने से इंकार कर देता है।
याद रखें कि DBAPI को इस तरह से डिज़ाइन किया गया है कि कोई भी डेटाबेस का उपयोग उसी एपीआई के साथ किया जा सकता है, भले ही वह डेटाबेस सभी डीबीएपीआई सुविधाओं का समर्थन न करे। विचार करें कि DBAPI को कर्सर के आसपास डिज़ाइन किया गया है, लेकिन MySQL वास्तव में है . नहीं है कर्सर! इसके बजाय, MySQL के लिए DBAPI एडेप्टर को उन्हें नकली बनाना होगा।
तो जबकि कर्सर.fetchmany(100) काम करेगा , आप MySQLdb<से देख सकते हैं /कोड> स्रोत कोड
कि यह सर्वर से आलस्य से नहीं आता है; यह सब कुछ एक बड़ी सूची में लाता है, फिर जब आप fetchmany . को कॉल करते हैं तो एक टुकड़ा देता है ।
क्या psycopg2 समर्थन सच्ची स्ट्रीमिंग है, जहां परिणाम लगातार याद किए जाते हैं सर्वर पर, और आपकी पायथन प्रक्रिया एक बार में उनमें से कुछ को ही देखती है।
आप अब भी यील्ड_परका उपयोग कर सकते हैं MySQLdb . के साथ , या कोई अन्य डीबीएपीआई; यह डीबीएपीआई के डिजाइन का पूरा बिंदु है। आपको DBAPI में छिपी हुई सभी कच्ची पंक्तियों के लिए मेमोरी लागत का भुगतान करना होगा (जो टुपल्स हैं, काफी सस्ते हैं), लेकिन आप भी नहीं करेंगे सभी ORM ऑब्जेक्ट्स के लिए एक ही समय में भुगतान करना होगा।
