Django साइट्स फ्रेमवर्क प्रारंभिक सेटअप

Question

मैं काफी एक-आयामी Django कार्यान्वयन के साथ सहज हूं, लेकिन अब बहु-साइट-साझा-साझा-सामग्री प्रक्रिया को समझने की कोशिश कर रहा हूं।

मैंने Django साइट्स फ्रेमवर्क और विषय पर कई पोस्टों के माध्यम से पढ़ा है, लेकिन मुझे एक ही डेटाबेस का उपयोग करने वाली दूसरी साइट को शुरू करने की मूल बातें नहीं मिल रही हैं, लेकिन खुद को एक अलग डोमेन नाम के रूप में प्रस्तुत करती है ।

मेरे पास एक परियोजना में चल रहे एक ऐप से युक्त एक बहुत ही खुश और द्वि-पुस्तक django साइट है।

ट्यूटोरियल की भाषा का उपयोग करने के लिए मैं

django-admin.py startproject mysite 

के साथ एक परियोजना "mysite" शुरू किया और उसके बाद

manage.py startapp polls 

Q1 के साथ एप्लिकेशन का "चुनाव" शुरू कर दिया: करता साइटें फ्रेमवर्क मान लें कि प्रत्येक साइट एक अलग परियोजना है या एक अलग ऐप है?

प्रोजेक्ट के भीतर एक दूसरा ऐप 'पोल 2' समझ में आता है, लेकिन सेटिंग.py जहां SITE_ID परिभाषित किया गया है, पूरी परियोजना प्रोजेक्ट है। ऐप-ए-एप सेटिंग्स बनाने का कोई मतलब है?

'mysite' के समीप एक दूसरा proj 'mysite2' मुझे अपनी सेटिंग्स.py और एक अलग SITE_ID के साथ दूसरी संरचना देगा, लेकिन फिर "DRY" सिद्धांत का बड़ा उल्लंघन होता है जैसा कि मैं होगा आसन्न बहन परियोजना के कई तत्वों को डुप्लिकेट करना।

प्रश्न 2: लगता है जैसे मुझे डेटाबेस मॉडल (models.py) को साइटों के बीच डेटा साझा करने के लिए कई से अधिक रिश्तों में फिर से परिभाषित करने की आवश्यकता होगी। क्या यह सिर्फ उन तालिकाओं तक पहुंचने के तरीके को बदलता है, या मौजूदा साइट के डेटाबेस को भी पुनर्निर्मित करने की आवश्यकता होगी?

साइट ढांचे को लागू करने के लिए इच्छित प्रक्रिया के बारे में आपका मार्गदर्शन बहुत अच्छा होगा और बहुत सराहना की जाएगी।

Answer 1

Q1: ब्लॉग फ्रेमवर्क मान करता है प्रत्येक साइट के लिए एक अलग परियोजना या अलग ऐप्स है?

एक Django वेबसाइट में आमतौर पर कई ऐप्स होते हैं, इसलिए "एकल ऐप" दृष्टिकोण वास्तव में काम नहीं करेगा। लेकिन हर साइट के लिए एक अलग परियोजना के संदर्भ में सोचना उपयोगी नहीं है। केवल चीज़ जो प्रत्येक साइट के लिए अलग होना है सेटिंग्स फ़ाइल है।

क्या प्रत्येक साइट के लिए एक अलग सेटिंग्स फ़ाइल है DRY सिद्धांत का उल्लंघन है? जरुरी नहीं। आप सामान्य सेटिंग्स के साथ एक बेस सेटिंग्स फ़ाइल बना सकते हैं (और चाहिए)। फिर आप उन्हें प्रति-साइट सेटिंग्स फ़ाइलों में आयात करेंगे।

अपनी परियोजना निर्देशिका में उदाहरण के लिए आप तीन सेटिंग्स फ़ाइलों हो सकता है:

base_settings.py 
siteA_settings.py 
siteB_settings.py 

siteA_settings.py और siteB_settings.pybase_settings.py से सभी सेटिंग्स आयात होगा।

केवल आपको लगता है कि को प्रति साइट सेटिंग फ़ाइलों में डाल दिया गया है SITE_ID एक व्यक्तिगत साइट आईडी के साथ सेटिंग है।अन्य सभी सेटिंग्स साइट्स (base_settings.py) पर साझा की जा सकती हैं या आपकी व्यक्तिगत जरूरतों के आधार पर किसी विशेष साइट (siteA_settings.py, siteB_settings.py) के लिए विशिष्ट हो सकती हैं। उदाहरण के लिए, यदि आपके पास प्रति साइट सेटिंग्स अलग-अलग हैं, तो प्रति साइट सेटिंग्स में TEMPLATE_DIRS सेटिंग को फिर से परिभाषित कर सकते हैं, लेकिन यदि टेम्पलेट्स उन साइटों पर साझा की जाती हैं जिन्हें आपको नहीं करना है। अन्य सभी सेटिंग्स के साथ ही - यूआरएल संरचना, स्थापित ऐप्स की सूची इत्यादि।

फिर आप सेटिंग फाइलों को निर्दिष्ट करके आप कौन सी साइट को चलाने के लिए चुनना चाहते हैं।

python manage.py runserver --settings=mysite.siteA_settings 

या

python manage.py runserver --settings=mysite.siteB_settings 

---

Q2:: Django विकास सर्वर के साथ उदाहरण के लिए ऐसा लगता है कि मैं एक many- में डेटाबेस मॉडल (models.py) को फिर से परिभाषित करने की आवश्यकता होगी साइटों के बीच डेटा साझा करने के लिए कई रिश्तों। क्या बस Django उन तालिकाओं तक पहुंचने का तरीका बदलता है, या मौजूदा साइट के डेटाबेस को भी पुनर्निर्मित करने की आवश्यकता होगी?

मॉडल जो अभी साइट्स के बीच साझा किए गए हैं, उन्हें संशोधित करने की आवश्यकता नहीं है, जब तक कि सभी ऑब्जेक्ट्स साझा नहीं किए जाते हैं। केवल उन मामलों में जब आप यह नियंत्रित करने में सक्षम होना चाहते हैं कि मॉडल का कौन सा ऑब्जेक्ट उस साइट पर दिखाई देता है, तो आपको अपने मॉडल से रिश्तों को जोड़कर (कई लोगों को या आपकी ज़रूरतों के आधार पर विदेशी कुंजी) जोड़कर इसकी आवश्यकता होती है। Django के Site मॉडल।

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

रिश्ते जोड़ने के बाद आप वर्तमान क्वेरी के लिए अपनी क्वेरी को आसानी से प्रतिबंधित कर सकते हैं - उदाहरण के लिए the CurrentSiteManager का उपयोग करके। दूसरी ओर आप डिफ़ॉल्ट प्रबंधक का उपयोग कर सभी ऑब्जेक्ट्स तक पहुंच सकते हैं (यानी ओआरएम तक पहुंचने के सामान्य Model.objects रूप)।