नहीं। CouchDB एक "आशावादी संगामिति" मॉडल का उपयोग करता है। सबसे सरल शब्दों में, इसका मतलब यह है कि आप अपने अपडेट के साथ एक डॉक्यूमेंट वर्जन भेजते हैं, और काउचबीडी परिवर्तन को अस्वीकार कर देता है यदि वर्तमान डॉक्यूमेंट वर्जन आपके भेजे गए मेल से मेल नहीं खाता है।
यह वास्तव में भ्रामक है। आप CouchDB के लिए कई सामान्य लेनदेन आधारित परिदृश्यों को फिर से नामांकित कर सकते हैं। हालांकि CouchDB सीखते समय आपको अपने RDBMS डोमेन ज्ञान को फेंकना होगा। काउच को SQL आधारित दुनिया में ढालने का प्रयास करने के बजाय उच्च स्तर से समस्याओं का सामना करने में मददगार है।
इन्वेंट्री का ट्रैक रखना
आपके द्वारा उल्लिखित समस्या मुख्य रूप से एक इन्वेंट्री समस्या है। यदि आपके पास एक आइटम का वर्णन करने वाला दस्तावेज़ है, और इसमें "मात्रा उपलब्ध" के लिए एक फ़ील्ड शामिल है, तो आप इस तरह से समसामयिक मुद्दों को संभाल सकते हैं:
- दस्तावेज़ को पुनः प्राप्त करें, उस
_revसंपत्ति का ध्यान रखें जिसे CouchDB साथ भेजता है
- मात्रा क्षेत्र घटाएँ, यदि यह शून्य से अधिक है
_revसंपत्ति का उपयोग करके अद्यतन दस्तावेज़ वापस भेजें- यदि
_revवर्तमान में संग्रहीत संख्या से मेल खाता है, तो किया जाए!
- यदि कोई संघर्ष है (जब
_revमेल नहीं खाता), तो नवीनतम दस्तावेज़ संस्करण पुनः प्राप्त करें
इस उदाहरण में, सोचने के लिए दो संभावित विफलता परिदृश्य हैं। यदि सबसे हाल के दस्तावेज़ संस्करण में 0 की मात्रा है, तो आप इसे उसी तरह से हैंडल करते हैं जैसे आप RDBMS में करते हैं और उपयोगकर्ता को सचेत करते हैं कि वे वास्तव में वे नहीं खरीद सकते जो वे खरीदना चाहते थे। यदि सबसे हाल के दस्तावेज़ संस्करण में 0 से अधिक की मात्रा है, तो आप बस अपडेट किए गए डेटा के साथ ऑपरेशन को दोहराते हैं, और शुरुआत में वापस आते हैं। यह आपको आरडीबीएमएस की तुलना में थोड़ा अधिक काम करने के लिए मजबूर करता है, और अगर लगातार, परस्पर विरोधी अपडेट होते हैं तो थोड़ा परेशान हो सकते हैं।
अब, मैंने जो उत्तर दिया है, वह बताता है कि आप काउचडीबी में उसी तरह से काम करने जा रहे हैं जैसे कि आप आरडीएसएमएस में करते हैं। मैं इस समस्या से थोड़ा अलग तरीके से संपर्क कर सकता हूं:
मैं एक "मास्टर उत्पाद" दस्तावेज़ के साथ शुरू करता हूं जिसमें सभी डिस्क्रिप्टर डेटा (नाम, चित्र, विवरण, मूल्य, आदि) शामिल हैं। फिर मैं प्रत्येक विशिष्ट उदाहरण के लिए "इन्वेंट्री टिकट" दस्तावेज़ जोड़ूंगा, product_keyऔर साथ के लिए फ़ील्ड claimed_by। आप हथौड़ा का एक मॉडल बेच रहे हैं, और बेचने के लिए उनमें से 20 है, तो आप की तरह कुंजी के साथ दस्तावेजों को हो सकता है hammer-1, hammer-2प्रत्येक उपलब्ध हथौड़ा प्रतिनिधित्व करने के लिए, आदि,।
फिर, मैं एक ऐसा दृश्य बनाऊंगा जो मुझे उपलब्ध हथौड़ों की एक सूची देता है, एक कम फ़ंक्शन के साथ जो मुझे "कुल" देखने देता है। ये पूरी तरह से कफ से बाहर हैं, लेकिन आपको यह अंदाजा लगाना चाहिए कि काम करने का तरीका कैसा होगा।
नक्शा
function(doc)
{
if (doc.type == 'inventory_ticket' && doc.claimed_by == null ) {
emit(doc.product_key, { 'inventory_ticket' :doc.id, '_rev' : doc._rev });
}
}
यह मुझे उत्पाद कुंजी द्वारा उपलब्ध "टिकट" की एक सूची देता है। मैं इनमें से एक समूह को पकड़ सकता हूं जब कोई हथौड़ा खरीदना चाहता है, तो अपडेट भेजने के माध्यम से पुनरावृति ( तब idऔर _revतब तक) जब तक मैं सफलतापूर्वक एक दावा नहीं करता (पहले दावा किए गए टिकट एक अपडेट त्रुटि का परिणाम होगा)।
कम करना
function (keys, values, combine) {
return values.length;
}
यह कम करने वाला फ़ंक्शन केवल लावारिस inventory_ticketवस्तुओं की कुल संख्या लौटाता है , इसलिए आप बता सकते हैं कि कितने "हथौड़ों" की खरीद के लिए उपलब्ध हैं।
चेतावनियां
यह समाधान आपके द्वारा प्रस्तुत विशेष समस्या के लिए कुल सोच का लगभग 3.5 मिनट का प्रतिनिधित्व करता है। ऐसा करने के बेहतर तरीके हो सकते हैं! इसने कहा, यह परस्पर विरोधी अपडेट को काफी हद तक कम करता है, और एक नए अपडेट के साथ संघर्ष का जवाब देने की आवश्यकता पर कटौती करता है। इस मॉडल के तहत, आपके पास कई उपयोगकर्ता प्राथमिक उत्पाद प्रविष्टि में डेटा बदलने का प्रयास नहीं करेंगे। सबसे खराब स्थिति में, आपके पास एक ही टिकट का दावा करने का प्रयास करने वाले कई उपयोगकर्ता होंगे, और यदि आपने उनमें से कई को अपने दृश्य से पकड़ लिया है, तो आप बस अगले टिकट पर जाते हैं और फिर से प्रयास करते हैं।
संदर्भ: https://wiki.apache.org/couchdb/Frequently_asked_questions#How_do_I_use_transactions_with_CouchDB.3F