Django और MySQL में लेनदेन के उपयोग की सुविधाएँ

शायद सभी जानते हैं कि अजगर में वेब विकास के लिए Django सबसे लोकप्रिय रूपरेखाओं में से एक है। और भले ही वेब-परियोजना तीसरे पक्ष के कोड पर आधारित हो, अक्सर विकास के दौरान वे इस ढांचे के अलग-अलग हिस्सों का उपयोग करते हैं - उदाहरण के लिए, ओआरएम। इस लेख में, मैं एक MySQL डेटाबेस के साथ काम करते समय Django ORM का उपयोग करने की विशेषताओं के बारे में बात करना चाहूंगा, अर्थात् लेनदेन और उनके साथ जुड़े नुकसान के बारे में। इसलिए, उदाहरण के लिए, यदि किसी बिंदु पर आपको पता चलता है कि अपेक्षित डेटा के बजाय, एक पूरी तरह से अलग परिणाम लौटा है, तो शायद यह लेख यह पता लगाने में मदद करेगा कि क्या है।

इसके बाद, हम InnoDB के बारे में बात करेंगे, क्योंकि यह एकमात्र इंजन है जो MySQL के भाग के रूप में चल रहा है और लेनदेन का पूर्ण समर्थन करता है (BDB की गिनती नहीं है, क्योंकि यह लंबे समय से समर्थित नहीं है)।
यह कई विशेषताओं को ध्यान देने योग्य है:
1. Django में, MySQLdb एक्सटेंशन का उपयोग MySQL के इंटरफ़ेस के रूप में किया जाता है, और यह, बदले में, इंस्टॉल करता है :

AUTOCOMMIT=0 

यही है, प्रत्येक डेटा संशोधन ऑपरेशन को परिवर्तनों को वापस करने या रोल करने के लिए एक COMMIT / रोलबैक पूरा करना होगा। यदि आप MySQL तक पहुँचने के लिए PHP एक्सटेंशन (पीडीओ, मैसकली) या रूबी का उपयोग करते हैं, तो आप शायद थोड़ा आश्चर्यचकित होंगे, क्योंकि कनेक्ट करते समय लगभग सभी डेटाबेस एक्सेस ड्राइवरों में, AUTOCOMMIT मान नहीं बदलता (और डिफ़ॉल्ट रूप से MySQL में यह AUTOCOMMIT = 1 पर सेट है) )।
2. MySQL REPEATABLE-READ लेनदेन अलगाव स्तर का उपयोग करता है, इसके विपरीत, उदाहरण के लिए, PosgreSQL या Oracle, जिसमें डिफ़ॉल्ट लेनदेन अलगाव स्तर READ-COMMITTED है ।
इसका क्या मतलब है? एक विशिष्ट उदाहरण पर विचार करें:

 CREATE TABLE IF NOT EXISTS `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `test` VALUES (NULL, 'a'); 

Repeatable-पढ़ें

पहला लेनदेन:	दूसरा लेनदेन:
सेट AUTOCOMMIT = 0;	सेट AUTOCOMMIT = 0;
का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | + ---- + ------- +
	INSERT INTO `परीक्षण` वाल्व (NULL, 'b'); का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | | 2 | बी | + ---- + ------- + COMMIT;
INSERT INTO `test` VALUES (NULL, 'c'); का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | | 3 | सी | + ---- + ------- + COMMIT;

जैसा कि आप उदाहरण से देख सकते हैं, पहले डेटा रीडिंग के बाद पहले लेन-देन में, बाद के सभी रीडिंग बिल्कुल उसी परिणाम पर लौटेंगे जब तक कि COMMIT नहीं होता है, भले ही अन्य लेनदेन में क्या होता है।

पढ़ें-कटिबद्ध

पहला लेनदेन:	दूसरा लेनदेन:
सत्र सेट करें tx_isolation = 'READ-COMMITTED'; सेट AUTOCOMMIT = 0;	सत्र सेट करें tx_isolation = 'READ-COMMITTED'; सेट AUTOCOMMIT = 0;
का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | + ---- + ------- +
	INSERT INTO `परीक्षण` वाल्व (NULL, 'b');
का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | + ---- + ------- +
	का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | | 2 | बी | + ---- + ------- + COMMIT;
INSERT INTO `test` VALUES (NULL, 'c'); का चयन करें * से `परीक्षण`; + ---- + ------- + | आईडी | मूल्य | + ---- + ------- + | 1 | ए | | 2 | बी | | 3 | सी | + ---- + ------- + COMMIT;

READ-COMMITTED के मामले में, SELECT हमेशा डेटा के अंतिम प्रतिबद्ध संस्करण को लौटाता है।

Django के विषय पर वापस लौटना - Django ORM का उपयोग करने में पकड़ यह है कि READ-COMMITTED को केवल लेन-देन अलगाव स्तर प्रतीत होता है जिसे डेवलपर्स ने ध्यान केंद्रित किया है। इसलिए, उदाहरण के लिए, यदि हम Django कोड को देखते हैं, अर्थात्, QuerySet वर्ग में get_or_create () पद्धति का कार्यान्वयन :

  def get_or_create(self, **kwargs): """ Looks up an object with the given kwargs, creating one if necessary. Returns a tuple of (object, created), where created is a boolean specifying whether an object was created. """ assert kwargs, \ 'get_or_create() must be passed at least one keyword argument' defaults = kwargs.pop('defaults', {}) lookup = kwargs.copy() for f in self.model._meta.fields: if f.attname in lookup: lookup[f.name] = lookup.pop(f.attname) try: self._for_write = True return self.get(**lookup), False except self.model.DoesNotExist: try: params = dict([(k, v) for k, v in kwargs.items() if '__' not in k]) params.update(defaults) obj = self.model(**params) sid = transaction.savepoint(using=self.db) obj.save(force_insert=True, using=self.db) transaction.savepoint_commit(sid, using=self.db) return obj, True except IntegrityError, e: transaction.savepoint_rollback(sid, using=self.db) exc_info = sys.exc_info() try: return self.get(**lookup), False except self.model.DoesNotExist: # Re-raise the IntegrityError with its original traceback. raise exc_info[1], None, exc_info[2] 

फिर वस्तु को पुनः प्राप्त करने का दूसरा प्रयास:

 return self.get(**lookup), False 

हमेशा विफल रहेगा।
मैं समझाने की कोशिश करूँगा - उदाहरण के लिए, दो प्रक्रियाएँ एक साथ एक निश्चित मॉडल के get_or_create () विधि को बुलाती हैं । पहली प्रक्रिया डेटा को पढ़ने की कोशिश करती है - कोई डेटा नहीं है, एक DoNotExist अपवाद फेंक दिया गया है । दूसरी प्रक्रिया समान रूप से डेटा पढ़ने की कोशिश करती है और इसी तरह एक DoNotExist अपवाद को फेंकता है। इसके अलावा, चूंकि कनेक्शन AUTOCOMMIT = 0 और लेन-देन अलगाव स्तर REPEATABLE-READ का उपयोग करता है, दोनों प्रक्रियाएं रीड डेटा को फ्रीज करती हैं। मान लीजिए कि पहली प्रक्रिया सफलतापूर्वक एक रिकॉर्ड बनाती है और बनाए गए रिकॉर्ड की वस्तु को वापस करती है। लेकिन एक ही समय में, दूसरी प्रक्रिया कुछ भी नहीं बना सकती है, क्योंकि यह विशिष्टता की बाधा का उल्लंघन करेगी। मजेदार बात यह है कि वह पहली प्रक्रिया में बनाई गई वस्तु को नहीं देखता है, इस तथ्य के कारण कि जब डेटा फिर से पढ़ा जाता है, तो एक "जमे हुए" परिणाम वापस आ जाता है।
बेशक, प्रायोगिक स्थितियों में इस त्रुटि को पुन: पेश करना काफी समस्याग्रस्त है, लेकिन कई प्रतिस्पर्धी अनुरोधों के साथ, यह कोड अस्थिर होगा, समय-समय पर एक DoNotExist अपवाद को फेंक देगा ।
इससे कैसे निपटें?
1. यदि आप get_or_create () विधि का उपयोग करते हैं, तो अपना स्वयं का तरीका लिखें जो डेटा पढ़ने से पहले एक मजबूर COMMIT निष्पादित करता है:

 @transaction.commit_manually() def custom_get_or_create(...): try: obj = SomeModel.objects.create(...) except IntegrityError: transaction.commit() obj = SomeModel.objects.get(...) return obj 

2. MySQL सेटिंग्स (/etc/mysql/my.cnf) में, READ-COMMITTED लेनदेन आइसोलेशन स्तर का उपयोग करें:

 transaction-isolation = READ-COMMITTED 

3. Django> = 1.2 संस्करण का उपयोग करते समय, डेटाबेस कनेक्शन विकल्पों में सेटिंग कोड में निम्न कोड का उपयोग करें:

 DATABASE_OPTIONS = { "init_command": "SET storage_engine=INNODB, SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED", } 

यह बग लंबे समय तक Django बग ट्रैकर पर प्रकाशित किया गया था, लेकिन अब तक टिकट बंद नहीं हुआ है और समस्या अभी भी प्रासंगिक है।

या यहाँ एक और उदाहरण है - मान लें कि Django ORM वेब सर्वर से अलग से उपयोग किया जाता है, एक डेमॉन के भाग के रूप में जो लगातार मेमोरी में लटका रहता है और समय-समय पर MySQL टेबल से नए डेटा को पढ़ता है। यह प्रयोग Django में निर्मित शेल का उपयोग करके किया जा सकता है:

 python manage.py shell >>> from test_module.models import * >>> len(SomeModel.objects.all()) 10 

अगला, दूसरे टर्मिनल का उपयोग करते हुए, कुछ प्रविष्टियाँ जोड़ें:

 >>> SomeModel(name='test1').save() >>> SomeModel(name='test2').save() >>> len(SomeModel.objects.all()) 12 

और यद्यपि दूसरे टर्मिनल में परिवर्तन स्पष्ट हैं, पहले टर्मिनल में ये नई जोड़ी गई प्रविष्टियाँ अभी भी अनुपलब्ध रहेंगी, जैसा कि शुरू किया गया लेन-देन पूरा नहीं हुआ है, और डेटा के पहले पढ़ने के बाद, बाद के सभी रीडिंग उसी परिणाम को वापस कर देंगे जब तक कि COMMIT को जबरन नहीं कहा जाता है।
इससे क्या लेना-देना? Mysql सेटिंग्स (my.cnf) में या Django में settings.py में डेटाबेस कनेक्शन सेटिंग्स में लेनदेन अलगाव स्तर बदलें। खैर, या प्रत्येक पढ़ने के बाद डेटा को मजबूर करें:

 >>> from django.db import connection, transaction >>> len(Param_Type.objects.all()) 10 >>> transaction.commit_unless_managed() >>> len(Param_Type.objects.all()) 12 

यह सब क्यों हो रहा है? शायद यह इस तथ्य के कारण है कि Django मूल रूप से एक डेटाबेस के रूप में PostgreSQL का उपयोग करके काम करने के लिए डिज़ाइन किया गया था, जो कि ऊपर वर्णित है, READ-COMMITTED का उपयोग बॉक्स से बाहर करता है। सामान्य तौर पर, MySQL InnoDB के संबंध में Django ORM का यह काफी मानक व्यवहार बग को पकड़ने में काफी मुश्किल हो सकता है। इसलिए, अधिकांश स्थानों पर जहां वर्णित समस्या पर चर्चा की जाती है (विभिन्न ब्लॉगों में और स्टैकओवरफ्लो पर), यह दृढ़ता से अनुशंसा की जाती है कि READ-COMMITTED का उपयोग डिफ़ॉल्ट लेनदेन अलगाव स्तर के रूप में किया जाए, यह तर्क देते हुए कि READ-COMMITTED REPEATABLE-READ की तुलना में "अधिक उत्पादक" है।