2010-07-09 11 views
14

मैं PHP के लिए सिद्धांत ओआरएम (v1.2) के साथ प्रयोग कर रहा हूं। मैंने दो बच्चों के वर्ग "जिन" और "व्हिस्की" के साथ एक वर्ग "शराब" परिभाषित किया है। मैं वर्गों को तीन अलग डेटाबेस टेबल पर मैप करने के लिए ठोस विरासत (अधिकांश साहित्य में कक्षा तालिका विरासत) का उपयोग कर रहा हूं।PHP सिद्धांत 1.2 ओआरएम - कक्षा तालिका विरासत के साथ बहुलक प्रश्न

मैं निम्नलिखित को निष्पादित करने का प्रयास कर रहा हूँ:

$liquor_table = Doctrine_Core::getTable('liquor'); 
$liquors = $liquor_table->findAll(); 

प्रारंभ में, मैं उम्मीद $ शराब सभी शराब से युक्त एक Doctrine_Collection होने के लिए, चाहे वे व्हिस्की या जिन हो। लेकिन जब मैं कोड निष्पादित करता हूं, तो मुझे व्हिस्की और जिन डेटाबेस टेबल में कई पंक्तियों के बावजूद खाली संग्रह मिलता है। जेनरेट किए गए एसक्यूएल के आधार पर, मैं समझता हूं कि क्यों: ओआरएम "शराब" तालिका से पूछताछ कर रहा है, न कि व्हिस्की/जिन टेबल जहां वास्तविक डेटा संग्रहीत किया जाता है।

ध्यान दें कि जब मैं विरासत प्रकार को कॉलम एकत्रीकरण (सरल तालिका विरासत) पर स्विच करता हूं तो कोड पूरी तरह से काम करता है।

सभी व्याख्याकों वाले Doctrine_Collection को प्राप्त करने का सबसे अच्छा तरीका क्या है?

अद्यतन

कुछ और अनुसंधान के बाद, ऐसा लगता है कि मैं सिद्धांत "व्हिस्की" और "जिन" टेबल से परिणाम सेट गठबंधन करने के लिए पर्दे के पीछे किसी SQL UNION कार्रवाई करते जा करने के लिए उम्मीद कर रहा हूँ।

इसे पॉलिमॉर्फिक क्वेरी के रूप में जाना जाता है।

this ticket के अनुसार, यह कार्यक्षमता सिद्धांत 1.x में उपलब्ध नहीं है। यह 2.0 रिलीज के लिए नियत है। (CTI के लिए सिद्धांत 2.0 दस्तावेज़ भी देखें)।

तो इस जानकारी के प्रकाश में, इस कमी के आसपास काम करने का सबसे साफ, सबसे प्रभावी तरीका क्या होगा? एकल टेबल विरासत पर स्विच करें? दो डीक्यूएल प्रश्नों को निष्पादित करें और परिणामी Doctrine_Collections को मैन्युअल रूप से मर्ज करें?

उत्तर

3

इस समय के लिए सिद्धांत का एकमात्र स्थिर और उपयोगी विरासत मोड स्तंभ_गमन है। मैंने विभिन्न परियोजनाओं में दूसरों की कोशिश की है। कॉलम_ग्रेडेशन के साथ आप पॉलिमॉर्फिक प्रश्नों का अनुकरण कर सकते हैं। सामान्य रूप से विरासत कुछ ऐसा है जो सिद्धांत (1.x) में थोड़ी छोटी गाड़ी है। 2.x के साथ यह बदल जाएगा, इसलिए हमारे पास भविष्य में बेहतर विकल्प हो सकते हैं।

0

मैंने ओआरएम की शुरुआत (उत्पादन तैयार नहीं) की शुरुआत की है जो ठीक वही करेगा जो आप थोड़ी देर के लिए देख रहे हैं। बस इतना है कि मैं अवधारणा का सबूत हो सकता है। मेरे सभी अध्ययनों से उपज है कि आप कोड और डेटा (शराब तालिका में सबक्लास जानकारी) मिश्रण कर रहे हैं।

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

आप कैसे विवरण फैलाते हैं पूरी तरह से आपके ऊपर है। मुझे लगता है कि सबसे सामान्यीकृत (और अगर मैं यहां गलत हूं तो कोई भी मुझे सही कर सकता है) ऐसा करने का तरीका शराब की मेज में आपके शराब वर्ग में दिखाई देने वाले सभी क्षेत्रों को स्टोर करना है। फिर, प्रत्येक उप-वर्ग के लिए, एक सारणी होती है जो उप-वर्ग प्रकार से संबंधित विशिष्ट डेटा संग्रहीत करती है। वह बिंदु है जिस पर आप कोड और डेटा मिश्रण कर रहे हैं क्योंकि आपका कोड शराब तालिका को पढ़ रहा है ताकि उप-वर्ग का नाम शामिल हो सके।

मैं कारों & बाइक और मेरे उदाहरण के लिए उन दोनों के बीच कुछ न्यूनतम, फिर भी तुच्छ मतभेदों का उपयोग करेंगे:

Ride 
---- 
id 
name 
type 

(1, 'Sebring', 'Car') 
(2, 'My Bike', 'Bicycle') 

Bicycle 
------- 
id 
bike_chain_length 

(2, '2 feet') 

Car 
--- 
id 
engine_size 

(1, '6 cylinders') 

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

आशा है कि इससे मदद मिलती है!