के साथ CouchDB प्रति उपयोगकर्ता डेटाबेस परिदृश्य मैं सोच रहा था कि एक सिस्टम कैसे बनाया जाए जिसमें उपयोगकर्ता अन्य उपयोगकर्ताओं को संदेश भेज सकें। बेशक सभी को केवल अपने इनबॉक्स तक पहुंचने में सक्षम होना चाहिए, इसलिए इसके लिए हमें प्रति-उपयोगकर्ता डेटाबेस आधारभूत संरचना की आवश्यकता है। http://guide.couchdb.org/draft/notifications.html से उदाहरण के बाद, हम देखते हैं कि उपयोगकर्ता केवल संदेश प्राप्तकर्ता के डेटाबेस में डाल सकते हैं। सरल और प्रभावी।निजी संदेश प्रणाली
लेकिन यदि हम उपयोगकर्ताओं को प्राप्तकर्ता डेटाबेस नाम जानने की अनुमति नहीं देना चाहते हैं तो क्या होगा? क्या हमारा सिस्टम ऐसे संदेश दस्तावेज़ के के क्षेत्र (जो उपयोगकर्ता नाम, पूरी तरह से अपने डेटाबेस नाम से संबंधित नहीं हो सकता है) पर देख कर प्राप्तकर्ता 'डेटाबेस का समाधान हो जाएगा चाहते हैं:
{
"to": "john.kowalski",
"from": "jake.podolski",
"subject": "hi",
"message": "..."
}
ऐसा लगता है अतिरिक्त स्तर के लिए एक आदर्श कार्य है, लेकिन फिर यह कोई मज़ा और लायक नहीं एक सवाल होगा, इसलिए हम वाला कोशिश कर रहे हैं और प्रतिकृति के साथ इसे हल की तरह:
- उपयोगकर्ता संदेश दस्तावेज़ डालता मुख्य डेटाबेस
- प्रतिकृति में कार्य (हमारे पास प्रत्येक उपयोगकर्ता के लिए एक कार्य होगा) वह प्राप्त करता है फ़िल्टर का उपयोग कर दस्तावेज़ जो _changes फ़ीड से फ़ील्ड फ़िल्टर करता है। "John.kowalski" नाम फ़िल्टर फ़ंक्शन के लिए पैरामीटर के रूप में पारित किया जाएगा।
- दस्तावेज़ प्राप्तकर्ता डेटाबेस में समाप्त होता है।
हालांकि, यह एक समस्या पैदा करता है, क्योंकि मुख्य डेटाबेस सभी उपयोगकर्ताओं को दिखाना होगा! तो ... क्या होगा यदि हम उपयोगकर्ता-> मुख्य प्रतिकृति कार्य को भी जोड़ सकेंगे, ताकि संदेशों को उपयोगकर्ता डेटाबेस से मुख्य डेटाबेस में स्थानांतरित किया जा सके और फिर प्राप्तकर्ता डेटाबेस में रखा जा सके (हे भगवान, यह जटिल हो रहा है, हम इसे इस तरह हल करने की कोशिश करके अपना समय बर्बाद कर सकते हैं, लेकिन आज़माएं)।
- उपयोगकर्ता संदेश दस्तावेज़ डालता है उसके डेटाबेस में
- प्रतिकृति कार्य को हासिल करेगा कि दस्तावेज़, लेकिन क्योंकि इस मामले में फिल्टर उपयोगकर्ता के स्वामित्व में है, और इसलिए भरोसा नहीं किया जा सकता है, किसी भी तरह के फिल्टर समारोह का उपयोग नहीं कर सकते हैं।
- मुख्य डेटाबेस दस्तावेज़ को मान्य करता है - यह जांचता है कि फ़ील्ड स्रोत डेटाबेस से जुड़ा हुआ है।
- पिछले दृष्टिकोण में प्रयुक्त प्रतिकृति कार्य दस्तावेज़ प्राप्तकर्ता को स्थानांतरित करता है।
तीसरे चरण में यहां समस्या है (कि कदम के बिना, उन क्षेत्र से में फर्जी जानकारी भर कर किसी अन्य उपयोगकर्ता नाम से कार्य संदेश भेजने के लिए सक्षम हो जाएगा) - हम कैसे मान्यता को अतिरिक्त डेटा भेजने के लिए सक्षम हैं काम करता है, वहाँ केवल पैरामीटर के रूप में जहाँ तक मुझे पता हैं:
- वर्ष डॉक
- नया दस्तावेज़ उपयोगकर्ता
- संदर्भ (लॉग इन उपयोगकर्ता नाम, भूमिका, डाटाबेस जो दस्तावेज़ लिखा जा रहा है करने के लिए)
- सुरक्षा वस्तु?
1.1.0 में पेश किए गए प्रतिकृति डेटाबेस कार्यक्षमता पर ध्यान देकर, हम उपयोगकर्ता_एक्सएक्स संदर्भ को प्रतिकृति कार्य में पास कर सकते हैं। वास्तविक ऑब्जेक्ट जानकारी के विपरीत इस ऑब्जेक्ट के लिए कस्टम डेटा शामिल होना संभव होगा?कैसे CouchDB मानक पहुंच को संभालने के मानक तरीके को प्रभावित करेगा?
यदि यह संभव होगा, प्रतिकृति कार्य के पास उपयोगकर्ता_ctx के तहत पैरामीटर के रूप में प्राप्तकर्ता का नाम होगा, तो सत्यापन फ़ंक्शन फ़ील्ड से तुलना करने के लिए उस मान का उपयोग करेगा। उपयोगकर्ता के अलावा किसी अन्य व्यक्ति के रूप में संदेश भेजने के लिए कोई रास्ता नहीं होगा।
एक रिकॉर्ड के लिए, मैं इस तथ्य से काफी अवगत हूं कि मैं यहां प्रतिकृति का दुरुपयोग कर सकता हूं, और कुछ कार्यकर्ता कार्य व्यवस्थापक के रूप में चल रहे हैं (ताकि यह सभी डेटाबेस पढ़ सके) दस्तावेजों को एक और अधिक मजबूत और सरल तरीके से स्थानांतरित कर सकता है। – Bartosz