Drupal 7 में वेब सेवा के माध्यम से 3rd-पार्टी डेटा संरचनाओं को एकीकृत करने का सबसे विश्वसनीय और दोषपूर्ण तरीका क्या है?

Question

मैंने द्रुपल में दूरस्थ डेटा संरचनाओं को एकीकृत करने के लिए कई रणनीतियों को देखा है। रणनीतियों के रूप में विकसित करने के लिए लग रहा है कि कुछ मॉड्यूल स्थिर हो गए हैं और उपयोग के मामलों की कोशिश की गई है।

कल्पना कीजिए कि हमारे पास एक डेटा संरचना "किसान बाज़ार" है जो कई प्रकार के डेटा प्रकारों (बाजार, market_hours, vender, stall, उपज) आदि द्वारा दर्शाया जाता है जो कि REST API के माध्यम से उजागर होते हैं। बाहरी सेवा के लिए ID को Drupal से संबंधित करने की आवश्यकता होगी, अर्थात "बाज़ार" लोड करते समय हम 'market_hours' और 'stall' से डेटा हड़पना चाहेंगे। यह दर्शाने का सबसे अच्छा तरीका क्या होगा कि ड्रुपल में केवल-पढ़ी जाने वाली सामग्री के रूप में, जो एक नियमित आधार पर समन्वयित हो?

मैं निम्नलिखित मानदंडों के साथ इसका मूल्यांकन करने की कोशिश कर रहा हूं:

द्रुपाल में डेटा संरचनाएं:

नोड्स बनाम कस्टम एंटिटीज़

वेब सेवाओं से जुड़े कई परिदृश्य मैंने कस्टम संस्थाओं का उपयोग करते हुए देखे हैं। यह CRUD ऑप को सरल करता है। हालाँकि, ये आइटम "सामग्री" होंगे, जिसमें उन्हें सार्वजनिक रूप से देखा जाएगा।

भंडारण (स्थानीय बनाम रिमोट):

मैंने ऐसे कुछ उदाहरण देखे हैं जहाँ सेवाओं को दूरस्थ संस्थाओं के रूप में लोड किया जाता है, जो इस मॉड्यूल के लिए एक पुस्तकालय बनाता है: https://drupal.org/project/wsdata । यह सबसे आकर्षक लगता है, लेकिन उपयोग के कई मामलों को नहीं देखा है। कस्टम कोड के उदाहरण भी हैं: https://drupal.org/sandbox/fago/1493180

डेटा सिंक करना:

फ़ीड्स बनाम माइग्रेट बनाम गज़ल बनाम 'वेब सेवा क्लाइंट' बनाम 'वेब सेवा डेटा'

कई विकल्प हैं। फ़ीड अब संस्थाओं का समर्थन करता है। माइग्रेट फ़ीड की तुलना में बहुत अधिक क्लीनर लगता है, खासकर कस्टम परिदृश्यों के लिए। मैंने दूरस्थ सेवाओं के साथ सिंक हड़पने के लिए एक गज़ल क्लाइंट का उपयोग करते हुए लोगों को भी देखा है: http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:.ckan.drush। inc # l273 । मैंने यह भी देखा है कि WS क्लाइंट मॉड्यूल https://drupal.org/project/wsclient एक विकल्प प्रदान करता है जो विशेष रूप से एक बाकी क्लाइंट के रूप में बनाया गया है। वेब सेवा डेटा एक सेवा से सीधे लोड होता है और इसे स्थानीय रूप से कैश करता है।

किसी भी विचार के लिए धन्यवाद।

Comments

मुझे यकीन नहीं है कि कोई भी आपको इस बात पर निश्चित जवाब दे सकता है कि यह आपके विशिष्ट उपयोग के मामले के लिए सबसे विश्वसनीय और दोषपूर्ण सहिष्णु समाधान है।

— रॉबी

"डेटा" मॉड्यूल एक और संभावना है, जिसका उपयोग फीड्स मॉड्यूल के साथ संयोजन में किया जा सकता है (वर्तमान में इस मुद्दे में समाधान की आवश्यकता है - drupal.org/node/1033202 )

— rooby

डेटा मॉड्यूल का उपयोग करने से हमें व्यक्तिगत तालिकाओं में डेटा संग्रहीत करने की अनुमति मिलेगी। यह विचारों के माध्यम से सूची बनाने के लिए ठीक होगा, लेकिन हमें इकाई प्रणाली (चाहे नोड्स या कस्टम संस्थाओं) के लाभों का उपयोग करने की अनुमति नहीं देगा।

— एक्यूप

हां, डेटा मॉड्यूल में एक सबमॉड्यूल data_entity है, जो आपके सभी डेटा आइटम की इकाइयाँ बनाता है।

— रॉबी

Answer 1

1. प्रश्न का सुधार

आपका उदाहरण बताता है कि डेटा को केवल Drupal साइड पर पढ़ा जाता है, केवल एक-तरफा सिंकिंग के साथ। मुझे लगता है कि यह यहां पर विचार करने के लिए सबसे महत्वपूर्ण कारक है, क्योंकि आप जो भी समाधान लागू करते हैं, वह रिमोट स्टोरेज, सिंकिंग और स्थानीय कैशिंग का एक प्रकार होगा - भले ही स्थानीय कैचिंग ड्रुपल डेटाबेस में एंटिटीज हो।

इसलिए प्रश्न, "स्थानीय भंडारण बनाम दूरस्थ भंडारण" होने के बजाय यह होने जा रहा है:

• क्या आपको डेटा को स्थानीय रूप से कैश करना चाहिए;
• क्या आपको डेटा को वास्तविक संस्थाओं के रूप में कैश करना चाहिए, और डेटा को नियमित रूप से सिंक्रनाइज़ करने के लिए फीड्स (या समान) का उपयोग करना चाहिए; या
• क्या आपको कुछ कस्टम मेड मॉड्यूल का उपयोग करना चाहिए जो सिंकिंग और कैशिंग प्रदान करता है।

आपकी रुचि का एक लेख " ड्रुपल 7 में रिमोट एंटिटीज़ " में है।

2. डेटा कैशिंग

सामान्य तौर पर, डेटा को कैशिंग करना एक अच्छा विचार है:

• आप कनेक्शन में अन्य सेवाओं या टाइमआउट के आउटेज के खिलाफ सुरक्षित हैं;

• आपके Drupal डेटाबेस में मौजूद आपका डेटा होने से संचालन में तेजी आएगी;

• आपके Drupal डेटाबेस में मौजूद आपका डेटा होने का मतलब होगा कि आपको अन्य मॉड्यूल के साथ एकीकरण प्राप्त करने की अधिक संभावना है, जैसे कि दृश्य (हालांकि यह गारंटी नहीं है)।

डेटा को कैशिंग न करने का एकमात्र लाभ यह है कि आपको कभी भी बासी डेटा नहीं मिलता है, जो कुछ मामलों में बेहतर होता है - कभी-कभी यह बासी डेटा के बजाय कोई डेटा प्रदर्शित करना बेहतर होता है। मैं इसे आपके द्वारा दिए गए उदाहरण में एक लाभ के रूप में नहीं देखता हूं, इसलिए मैं इस जवाब को एक समाधान पर ध्यान केंद्रित करूंगा जिसमें स्थानीय कैशिंग शामिल है।

3. स्थानीय निकाय + सिंकिंग

यदि आप स्थानीय निकाय रखने और उन्हें स्वयं समकालने के विकल्प के लिए जाते हैं, तो हम आपके मूल प्रश्नों पर वापस आते हैं:

• क्या आपको नोड्स या कस्टम संस्थाओं का उपयोग करना चाहिए;

• कौन सा मॉड्यूल सिंक करने के लिए सबसे अच्छा है।

3.1 नोड्स बनाम कस्टम इकाइयां

• जो वास्तव में नोड है, उसकी परिभाषा काफी खुली हुई है। नोड्स पर प्रलेखन पेज पता चलता है कि नोड्स "पोस्टिंग" है कि "संग्रहीत" कर रहे हैं अपनी साइट पर कर रहे हैं - न जिनमें से अपने डेटा पर लागू;

• एक Drupal डेवलपर के रूप में मुझे उम्मीद है कि अगर कुछ नोड है तो मुझे इसे साइट पर ही हेरफेर करने में सक्षम होना चाहिए;

• Drupal उपयोगकर्ता के रूप में, मैं इसी तरह उम्मीद करूंगा कि नोड्स को संपादित किया जा सकता है;

• यह Drupal 8 अंक https://drupal.org/node/2019031 बताता है कि "रीड ओनली" की अवधारणा एक है जो इकाई स्तर पर लागू होगी, बजाय बंडल स्तर के। यदि यह कभी लागू हो जाता है तो आप इस मार्ग से नीचे जाने से लाभान्वित होंगे।

संक्षेप में: आपका डेटा केवल पढ़ा जा रहा है और दूरस्थ रूप से संग्रहीत किया गया है, यह आपके डेटा का प्रतिनिधित्व करने के लिए कस्टम इकाई प्रकार का उपयोग करने के लिए अधिक समझ में आता है।

3.2 सिंकिंग

दूसरे भाग के लिए, इसके लिए दो मुख्य मॉड्यूल हैं, जैसा कि आप सुझाव देते हैं, फीड और माइग्रेट ।

फ़ीड्स और माइग्रेट के बीच का अंतर यह है कि फ़ीड्स सामग्री के नियमित आयात के लिए निर्मित होती हैं, जबकि माइग्रेट सामग्री के एक स्थान से दूसरे स्थान पर पोर्ट बंद करने के लिए निर्मित होता है। माइग्रेट मौजूदा डेटा को अपडेट करने का समर्थन करता है, हालांकि यह देखते हुए कि दोनों मॉड्यूल अच्छी तरह से समर्थित हैं यह उस मॉड्यूल का उपयोग करने के लिए अधिक समझ में आता है जो हाथ में कार्य के लिए बनाया गया था - फीड्स एक बेहतर मैच है।

दोनों मॉड्यूल्स का स्वयं उपयोग करना (फीड्स फॉर सिंकिंग, माइग्रेटिंग फॉर माइग्रेटिंग) मुझे फीड्स माइग्रेट से अधिक गन्दा नहीं लगता है। माइग्रेट को मेरे अनुभव में अधिक कस्टम कोड की आवश्यकता है, हालांकि संपूर्ण साइटों को माइग्रेट करना एकल सामग्री प्रकारों को आयात करने की तुलना में अधिक जटिल है, इसलिए इसकी तुलना करना कठिन है।

4. दूरस्थ भंडारण के लिए कस्टम मॉड्यूल, सिंकिंग + कैशिंग

वहाँ कई मॉड्यूल हैं जो इस कार्य में मदद कर सकते हैं।

आपने वेब सेवा डेटा मॉड्यूल का उल्लेख किया है, और अन्य लोगों ने डेटा मॉड्यूल का उल्लेख किया है । एक अन्य विकल्प पर विचार करने के लिए रिमोट एंटिटी एपीआई मॉड्यूल है । ध्यान दें कि जिन लोगों के पास मेरा अनुभव है उनमें से केवल एक डेटा मॉड्यूल है।

• वेब सेवा डेटा मॉड्यूल में अभी तक एक रिलीज नहीं है - जो यह संकेत दे सकता है कि कोड अभी तक स्थिर नहीं है, एपीआई बदल सकता है और इसी तरह। यह एंटिटी फील्ड क्वेरीज़ (प्रोजेक्ट पृष्ठ के अनुसार) का समर्थन नहीं करता है, और कोड रिपॉजिटरी का एक त्वरित ब्राउज़ दृश्य समर्थन का कोई सबूत नहीं दिखाता है - इसलिए आप अपनी संस्थाओं को प्रदर्शित करने के लिए दृश्यों का उपयोग करने में सक्षम नहीं होंगे;

• डेटा मॉड्यूल मेरे अनुभव में, गैर-डेवलपर्स के प्रति अधिक उन्मुख है, जिनके पास एक तालिका में डेटा है और इसे विचारों को उजागर करना चाहते हैं। मैंने Drupal 6 संस्करण को उपयोग करने के लिए काफी निराशाजनक पाया है - हालाँकि तब से शायद यह बदल गया है;

• रिमोट एंटिटी एपीआई मॉड्यूल काफी आशाजनक लगता है - यह दूरस्थ संस्थाओं के लाने और कैशिंग का समर्थन करता है, और इसमें दृश्य समर्थन है। यह केवल अल्फा रिलीज पर है - इसलिए एपीआई अभी भी बदल सकता है। पहली नज़र में ऐसा लगता नहीं है कि एंटिटी फील्ड क्वेरी का समर्थन है, और यह केवल एक प्रकार की दूरस्थ सेवा का समर्थन करता है, इसलिए आपको अपना स्वयं का कार्यान्वयन करना होगा।

निष्कर्ष

यह देखते हुए कि कोई भी रिमोट स्टोरेज मॉड्यूल Entity Field Queries का समर्थन नहीं करता है, वास्तविक संस्थाओं + फीड का उपयोग करना एक ऐसा समाधान है जो आपको अपने Drupal साइट के साथ सबसे अच्छा एकीकरण देगा।

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

Comments

बहुत बढ़िया जवाब! फीड्स बनाम माइग्रेट के संबंध में एक बात मैं यह कहूंगा कि माइग्रेट के पास डेटासेट के भीतर और डेटासेट के बीच संदर्भों को संभालने का एक अच्छा तरीका है। drupal.org/node/1013506

— मीलों

मैंने बस दूरस्थ इकाई एपीआई के साथ दृश्य समर्थन के साथ चीजों को स्थापित करने पर एक लेख लिखा था। देखें Drupal 7 में दूरस्थ डेटा का घालमेल और दृश्य के संपर्क में लाने ।

— कॉलन

Answer 2

अगर आपको अपने विचार, नियम, टोकन, क्रूड हुक, सर्च एपी और मेरी राय में निश्चित रूप से मजबूत सिस्टम एकीकरण की आवश्यकता है, तो उन्हें नोड नहीं माना जा सकता है, लेकिन उन्हें डेटाबेस में "निकाय आईडी" और अपने स्वयं के idiosyncrasy स्टोरेज के साथ कस्टम इकाइयाँ होनी चाहिए "बाहरी आईडी" संबंध और पुनर्प्राप्ति जानकारी के साथ "इकाई गुण" में समझाया गया है। अंत में, जो भी उपकरण आप डेटा समन्वयित करने के लिए चुनते हैं, मैं इसे क्रोन क्यूस के साथ संसाधित करूंगा।

यदि आपको केवल डेटा को पुनः प्राप्त करने और समय पर उजागर करने की आवश्यकता है, तो मुझे लगता है कि एक बेहतर विकल्प बाहरी डेटा को पुनर्प्राप्त करने के लिए एक इंटरफ़ेस वर्ग बनाएगा और इस इंटरफ़ेस को उस वर्ग के साथ कार्यान्वित करेगा जो आपके "किसान बाज़ार" संरचना से जानकारी पुनर्प्राप्त करता है।

सादर

Answer 3

नहीं है फील्ड भंडारण एपीआई , जो डिफ़ॉल्ट डेटाबेस इंजन के अलावा अन्य प्लगेबल भंडारण बैक समाप्त होता है के लिए अनुमति देता है।