2010-03-09 6 views
5

मैं डिजाइन द्वारा जोड़े गए कुछ django ऐप्स लिख रहा हूं। लेकिन मुझे सर्कुलर आयात की समस्याएं मिलती हैं। मुझे पता है कि यह खराब डिजाइन हो सकता है, इसलिए कृपया बेहतर समाधान के उदाहरण दें, लेकिन मुझे एक बेहतर उपयुक्त डिजाइन नहीं मिल रहा है। तो यदि कोई बेहतर डिज़ाइन नहीं है, तो इसे कैसे हल करें?Django ऐप्स के साथ सर्कुलर आयात समस्याएं जिनके पास एक दूसरे पर निर्भरता है

यह मूल रूप से दो डीजेंगो ऐप्स है, कुछ मॉडलों के साथ, जो एक-दूसरे के पार ऐप-वार से संबंधित हैं। संक्षेप में प्रणाली एक घटना आधारित प्रणाली है। तो एक घटना मॉडल और एक कार्य मॉडल है। ये विभिन्न ऐप्स, घटनाक्रम और कार्य में रहते हैं। जब घटनाएं ट्रिगर होती हैं, तो मुझे यह जांचना होगा कि सरटेन कार्यों को हल किया गया है या नहीं, और जब कोई कार्य हल हो जाता है, तो यह कुछ अन्य घटनाओं को ट्रिगर कर सकता है।

घटनाओं मैं (जाँच करने के लिए करता है, तो इन कार्यों को हल कर रहे हैं) कार्यों के बारे में डाटा स्टोर करने की जरूरत है और कार्यों मैं घटनाओं के बारे में डाटा स्टोर करने की जरूरत है

तो (जो घटनाओं जब वे हल कर रहे हैं को गति प्रदान करने के लिए)

यहाँ कुछ है मेरे ऐप्स से नमूना कोड:

Events app 
models.py 

from tasks.models import Task 

class Event(models.Model): 
    ... 
    tasks = models.ManyToManyField(Task, help_text=_("Tasks we need to check if are solved before triggering this event.")) 
    ... 


Tasks app 
models.py 

from events.models import Event 

class Task(models.Model): 
    ... 
    events = models.ManyToManyField(Event, help_text=_("Events to trigger when this task i solved.")) 
    ... 

यह आयात कारण समस्याएं हो रही जब मैं मान्य करने के लिए प्रयास करें:

AttributeError: 'module' object has no attribute 'Event' 

तो यह कैसे हल करने के लिए? मैंने उम्मीद में कुछ django सहायक कार्यों का उपयोग करने की कोशिश की है कि इससे मदद मिलेगी, अधिक विशेष रूप से मैंने django.db.models.get_app और get_model फ़ंक्शंस का उपयोग सीधे आयात करने के बजाय मॉडल आयात करने का प्रयास किया है, लेकिन मुझे अभी भी मिलता है समस्या का।

बेशक मैं उन्हें एक ही ऐप में एकत्र कर सकता हूं, लेकिन मैं स्पष्ट रूप से विश्वास करता हूं कि उन्हें अलग-अलग ऐप्स में रहना चाहिए, क्योंकि वे अलग-अलग चीजों को संभालते हैं। लेकिन हाँ वे एक-दूसरे पर निर्भर हैं। अगर मैं आयात समस्याओं को हल नहीं कर सकता, तो इस बारे में कोई विचार कैसे डिजाइन करें?

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

उत्तर

7

दोनों मॉडलों को कई से अधिक फ़ील्ड की आवश्यकता नहीं है।

अपने मॉडल में कई से अधिक रिश्तों के दोनों पक्षों को न रखें।

जब आप एक से कई रिश्तों में डालते हैं, Django आपके लिए रिश्ते के दूसरी तरफ डालता है।

http://docs.djangoproject.com/en/1.1/topics/db/queries/#many-to-many-relationships

एक कई-से-अनेक संबंध के दोनों सिरों से दूसरे छोर तक स्वत: एपीआई पहुँच मिलता है। एपीआई सिर्फ को "पिछड़ा" एक से अधिक रिलेशनशिप के रूप में काम करता है।

"जब ईवेंट ट्रिगर होता है, तो मुझे यह जांचना होगा कि सरटेन कार्यों को हल किया गया है या नहीं"।

  • इसका मतलब है कि ईवेंट को किसी अन्य तरीके से ट्रिगर किया जा सकता है और किसी भी कार्य से स्वतंत्र है।

  • यदि कोई ईवेंट ट्रिगर किया जा सकता है और इससे कार्य की ओर जाता है, तो कार्य ईवेंट पर निर्भर करते हैं।

  • "जब एक कार्य हल किया जाता है, कि कुछ अन्य घटनाओं को गति प्रदान कर सकते हैं" इसका मतलब है कि कार्य घटनाक्रम पर निर्भर हैं। घटनाएं कार्य पर निर्भर नहीं हैं।

कार्य में घटनाओं के लिए कई से अधिक संदर्भ रखें। घटनाओं में कुछ भी नहीं रखो, क्योंकि कार्य और अन्य घटनाओं की एक श्रृंखला को ट्रिगर करने के लिए घटनाओं का उपयोग कहीं और किया जा सकता है। कुछ क्लाइंट एप्लिकेशन केवल ईवेंट आयात करेंगे।

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

+1

इस बारे में निश्चित है? यह वही कार्य और घटना नहीं है। एक कार्य कुछ घटनाओं को ट्रिगर कर सकता है, लेकिन वही घटनाएं नहीं जो जांच सकती हैं कि क्या कार्य हल हो गया है या नहीं। क्या आप मॉडल को आयात करने के लिए स्ट्रिंग नाम का उपयोग कर सकते हैं यदि यह एक ही ऐप में नहीं है? – espenhogbakk

+0

http://docs.djangoproject.com/en/dev/ref/models/fields/#lazy-relationships का कहना है कि आलसी संबंधों को क्रॉस-एपवाइज़ का उपयोग करना संभव है, इसलिए मैं इसे आज़माउंगा। – espenhogbakk

+1

@ एस्पेन क्रिस्टेंसेन: आपको किसी भी तरह परिपत्र को तोड़ना होगा। आपके पास * दोनों * स्थानों में बहुत से लोग नहीं हो सकते हैं, यह केवल एक ही स्थान पर होना चाहिए। एक चुनें। मैंने यह बताने के लिए प्रश्न को अद्यतन किया कि मैंने जो चुना वह उठाया। आप ईवेंट के बजाय कार्य चुन सकते हैं, लेकिन आपको बिल्कुल एक और केवल एक चुनना होगा। आप दोनों जगहों पर कई से ज्यादा रिश्तों नहीं हो सकते हैं। –

संबंधित मुद्दे