2011-08-12 6 views
16

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

/** 
* @Entity 
* @Table(name="actions") 
* @InheritanceType("JOINED") 
* @DiscriminatorColumn(name="type", type="string") 
* @DiscriminatorMap({"FOO" = "FooAction", "BAR" = "BarAction", ...}) 
*/ 
abstract class AbstractAction 
{ 
    ... 
} 
विभिन्न क्षेत्रों के साथ

मैं विभिन्न कार्यों का एक समूह है, सभी: मैं तो जैसे एक सार आधार वर्ग की है। उदा:

/** 
* @Entity 
* @Table(name="actions_foo") 
*/ 
class FooAction extends AbstractAction 
{ 
    ... 
} 

लेकिन अपने कार्यों (BarAction) AbstractAction द्वारा आपूर्ति की उन के अलावा किसी अतिरिक्त क्षेत्रों की जरूरत नहीं है में से एक। लेकिन मैं इसे कैसे मैप कर सकता हूं? मैंने @Table को छोड़कर या का उपयोग AbstractAction के रूप में करने का प्रयास किया, लेकिन इसका कोई प्रभाव नहीं पड़ा।

/** 
* @Entity 
* @Table(name="actions") 
*/ 
class BarAction extends AbstractAction 
{ 
    ... 
} 

@Table छोड़ना मुझे एक लापता तालिका BarAction के बारे में PDOException देता है। आधार वर्ग के @Table का उपयोग करते हुए मुझे देता है:

PDOException: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens 

तो, मैं यह कैसे मैप करते हैं?

संपादित करें: अब तक मैंने दो और चीजों की कोशिश की है।

मैं आशा व्यक्त की कि इस तरह से यह अब एक डेटाबेस तालिका की आवश्यकता होगी में BarAction से और साथ @Entity को हटाने @Table के रूप में की कोशिश की। यह काम नहीं करता है।

Doctrine\ORM\Mapping\MappingException: Class BarAction is not a valid entity or mapped super class. 

अगला मैं सिर्फ एक विदेशी कुंजी स्तंभ id के साथ अपने डेटाबेस में एक actions_bar तालिका बनाने की कोशिश की: इसके बजाय, मैं इस त्रुटि मिलती है। तब मैंने BarAction मैप किया। यह काम करता है (याय!) लेकिन यह एक अतिरिक्त एसक्यूएल टेबल रखने के लिए क्रूर और बदसूरत लगता है जिसकी मुझे आवश्यकता नहीं है।

तो, अभी भी एक बेहतर तरीका की तलाश में ...

+0

डी 2 के साथ मेरे 2 वर्षों के अनुभव के आधार पर और यह [दस्तावेज़ीकरण] (http://www.doctrine-project.org/docs/orm/2.0/en/reference/inheritance-mapping.html#class-table- विरासत), आप केवल एक प्रकार की विरासत के साथ जा सकते हैं। या तो आप तालिका तालिका में शामिल हो गए हैं और प्रत्येक इकाई के लिए एक अलग तालिका है या एक टेबल विरासत का चयन करें और अपनी सभी संस्थाओं को एक तालिका में रखें। (विज़ार्डज़ के लिए टिप्पणी जो कि अभी तक टिप्पणी करने के लिए प्रतिनिधि नहीं है) – Oded

+4

डी 2 और दस्तावेज़ीकरण के साथ मेरे 2 साल के अनुभव के आधार पर: http://www.doctrine-project.org/docs/orm/2.0/en/reference/ विरासत-mapping.html # कक्षा-तालिका-विरासत आप केवल एक प्रकार की विरासत के साथ जा सकते हैं। या तो आप तालिका तालिका में शामिल हो गए हैं और प्रत्येक इकाई के लिए एक अलग तालिका है या एक टेबल विरासत का चयन करें और अपनी सभी संस्थाओं को एक तालिका में रखें। – WizardZ

+0

@ सैंडर: क्या आपका 'बारक्शन' वास्तव में 'सार तत्व' का उप-वर्ग होना चाहिए? मुझे नहीं पता कि क्या आपके डोमेन मॉडल में पदानुक्रम की जड़ के रूप में 'बारएक्शन' होना समझ में आता है, लेकिन कार्यान्वयन बिंदु से, यह आपकी समस्या का समाधान करेगा, क्योंकि 'बारक्शन' केवल फ़ील्ड का उपयोग करेगा बेस टेबल! – Benjamin

उत्तर

2

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

और एक अभिभावक वर्ग केवल एक प्रकार की विरासत का उपयोग कर सकता है, या तो कक्षा तालिका विरासत या एकल तालिका विरासत।

उस स्थिति में, यदि आप इसमें केवल आईडी कॉलम वाला कोई टेबल नहीं चाहते हैं, तो आपको अपना डेटा मॉडल बदलना होगा।

2

हो सकता है कि इस मदद या कुछ नया जोड़ सकते हैं। यह जवाब देने का तरीका नहीं है बल्कि अवधारणाओं को लेना है।

यदि आप कक्षाओं पर सोचते हैं और आप अपने मॉडल को इस तरह समझते हैं: सार तत्व, FooAction और BarAction यह संभवतः इसलिए है क्योंकि आप subclasses पर किसी भिन्न तरीके से लागू या कुछ पैरेंट विधि को विस्तारित कर सकते हैं।

यदि आप इन वर्गों को तालिकाओं के साथ प्रस्तुत करना चुनते हैं और आप "एक भेदभावकर्ता विशेषता वाले एक तालिका में" चुनते हैं तो मुझे लगता है कि आपको कोई समस्या नहीं है। बारएक्शन के लिए आप भेदभावकर्ता = "बारएक्शन" के साथ पंजीकरण करेंगे, जिसे BarAction.php इकाई वर्ग द्वारा दोहराया जाएगा।

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

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

0

मुझे लगता है कि आपको अपने डेटाबेस में मैन्युअल रूप से तालिका बनाने की आवश्यकता नहीं है।

मेरे पास काफी समान संरचना है जिसे मैंने सिद्धांत (2.3) नौकरी दी है। हालांकि आपको प्रत्येक उप-वर्गों पर @Entity et @Table रखना होगा। त्रुटि अमान्य पैरामीटर संख्या: बाध्य चर की संख्या टोकन की संख्या से मेल नहीं खाती संबंधित नहीं हो सकता है। यह एक कैश समस्या हो सकती है, क्या आपने इसे फ्लश करने की कोशिश की है?

0

मैं भी इस समस्या में भाग गया, लेकिन मैंने अपनी विरासत इकाई में कुछ डमी गुणों को जोड़ा, यह सोचकर कि यह किसी भी समय उपयोगी हो सकता है। मुझे पता नहीं है कि यह सही विचार नहीं है, लेकिन इससे मुझे अपने डेटा मॉडल को बरकरार रखने में मदद मिली और मुझे भविष्य में विरासत वाली संस्थाओं में अपनी संपत्ति रखने की संभावना दी।