कोच डीबी _changes प्रतिक्रिया में, "परिवर्तन" तत्व सरणी क्यों हैं?

Question

कॉच डीबी से _changes अनुरोध की प्रतिक्रिया इस प्रारूप में वापस आती है: {"seq": 12, "id": "foo", "change": [{"rev": "1-23202479633c2b380f79507a776743d5"}]}

मेरा प्रश्न - "परिवर्तन" तत्व एक सरणी क्यों है? परिवर्तन तत्व में एक से अधिक आइटम कौन सा परिदृश्य वापस करेगा? मैंने कभी एक से अधिक आइटम के साथ ऑनलाइन उदाहरण नहीं देखा है, और अपने अनुभव में मैंने केवल एक आइटम देखा है।

मैं कोड लिख रहा हूं जो परिवर्तनों के साथ बातचीत करता है, और मैं समझना चाहता हूं कि क्या करना है, वास्तव में, एक से अधिक आइटम थे।

धन्यवाद, माइक

Answer 1

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

1. माइक डेटाबेस एक में दस्तावेज़ बनाया और डेटाबेस बी करने के लिए उसे दोहराया है

   { "परिणाम" [ { "seq": 1, "id": "बात", "परिवर्तन": [{ "रेव": "1-967a00dff5e02add41819138abb3284d"}]} ], "last_seq": 1}

2. जॉन डेटाबेस बी में अपने दस्तावेज़ प्राप्त किया है और अद्यतन उसे:

   { "परिणाम": [ { "Seq": 2, "id": "बात", "परिवर्तन": [{ "रेव": "2-7051cbe5c8faecd085a3fa619e6e6337"}]} ], "last_seq": 2}

3. लेकिन पर उसी माइक ने डेटाबेस ए में:

   {"परिणाम": [ {"seq": 2, "id": "चीज़" में कुछ बदलाव किए हैं (डेटा को साफ़ करने या कुछ महत्वपूर्ण के लिए जोड़ने के लिए भूल गए हैं) , "परिवर्तन": [{ "रेव": "2-13839535feb250d3d8290998b8af17c3"}]} ], "last_seq": 2}

4. और उसे फिर से डेटाबेस बी को दोहरायाजॉन को विवाद स्थिति में दस्तावेज़ प्राप्त होता है और क्वेरी पैरामीटर style=all_docs के साथ परिवर्तन फ़ीड को देखकर अगला परिणाम देखें:

   {"परिणाम": [ {"seq": 3, "id": "चीज़", "परिवर्तन": [{ "रेव": "2-7051cbe5c8faecd085a3fa619e6e6337"}, { "रेव": "2-13839535feb250d3d8290998b8af17c3"}]} ], "last_seq": 3}

   दस्तावेज़ के लिए सीधी पहुँच विजेता से अपने डेटा देता है जबकि संशोधन (उच्च सीईसी संख्या या केवल नवीनतम के साथ) उनके लिए कई विवादित संशोधन होना संभव है (एक दूसरे के बीच दोहराए गए दर्जन डेटाबेस के भीतर एक दस्तावेज़ के लिए समवर्ती लिखने की कल्पना करें)

[ { "seq":

{ "परिणाम": 0

5. अब जॉन इस विरोध को हल और वास्तविक संशोधन अद्यतन करते हैं, लेकिन छोड़ अन्य का फैसला किया था 4, "id": "बात", "परिवर्तन" : [{ "रेव": "3-2502757951d6d7f61ccf48fa54b7e13c"}, { "रेव": "2-13839535feb250d3d8290998b8af17c3"}]} ], "last_seq": 4}

6. प्रतीक्षा, मोहन का संशोधन अभी भी वहाँ है ? क्यूं कर? , 5 "id"::

   { "परिणाम": [ { "seq" दहशत में जॉन ने अपने दस्तावेज़ को हटा "बात", "परिवर्तन": [{ "रेव": "2-13839535feb250d3d8290998b8af17c3"} { "रेव": "4-149c48caacb32c535ee201b6f02b027b"}]} ], "last_seq": 5}

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

7. प्रतिकृति जॉन डेटाबेस एक करने के लिए डेटाबेस बी से बदल जाता होगा सब लाता समाधि का पत्थर:

   { "परिणाम" [ { "seq": 3, "id": "बात", "परिवर्तन": [ { "रेव": "3-2adcbbf57013d8634c2362630697aab6"}, { "रेव": "4-149c48caacb32c535ee201b6f02b027b"}]} ], "last_seq": 3}

   क्यों इतने? चूंकि यह उनके डेटा "विकास" के बारे में दस्तावेज़ इतिहास है: वास्तविक दुनिया में आपके दस्तावेज़ों में बड़ी संख्या में डेटाबेस के बीच वितरित कई मध्यवर्ती पत्ते हो सकते हैं और चुप डेटा को डेटा प्रतिलिपि प्रक्रिया को ओवरराइट करने से रोकने के लिए CouchDB इस तरह के संघर्षों को हल करने में मदद के लिए प्रत्येक पत्ता रखता है। CouchDB विकी में replication and conflicts के बारे में अधिक और शायद बेहतर स्पष्टीकरण मिल सकता है। query parameters में परिवर्तन फ़ीड भी वर्णित हैं।