2017-11-08 57 views
5

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

उदाहरण:

select this_.person_id as y0_ from name this_ where this_.part_type='GIV' 

यह आपको जब तक इतना बुरा नहीं है:

@Entity 
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) 
@DiscriminatorColumn(name = "PART_TYPE") 
@Table(name = "NAME") 
public class NamePartEntity implements Comparable<NamePartEntity> { 
    // Stuff 
} 

@Entity 
@DiscriminatorValue(value = "GIV") 
public class GivenNameEntity extends NamePartEntity { 
    // stuff 
} 

अगर मैं वर्ग को छोड़कर कोई मापदंड के साथ एक सरल मापदंड क्वेरी बनाने के लिए, मैं एसक्यूएल इस तरह की तरह उत्पन्न मिलेगा कुछ हद तक भेदभाव मूल्यों का चयन किया जा सकता है और तालिका को कई बार चुना जा सकता है, जैसे कि नीचे की तरह एक क्वेरी:

SELECT this_.person_id AS y0_ 
FROM name this_ 
WHERE this_.part_type='FAM' 
AND this_.value_u =:8 
AND this_.tenant_id =:9 
AND this_.person_id IN 
    (SELECT this_.person_id AS y0_ 
    FROM name this_ 
    WHERE this_.part_type='GIV' 
    AND this_.value_u =:10 
    AND this_.tenant_id =:11 
    AND this_.person_id IN 
    (SELECT this_.person_id AS y0_ 
    FROM name this_ 
    WHERE this_.part_type='GIV' 
    AND this_.value_u =:12 
    AND this_.tenant_id =:13 
    AND this_.person_id IN 
     (SELECT this_.person_id AS y0_ 
     FROM name this_ 
     WHERE this_.part_type='PFX' 
     AND this_.value_u =:14 
     AND this_.tenant_id =:15 
    ) 
    ) 
) 

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

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

वैकल्पिक रूप से, क्या कोई तरीका है कि मैं अभी भी भेदभाव मूल्यों का उपयोग किए बिना अपने विस्तारित कक्षाओं का उपयोग कर सकता हूं? यदि मैं कोशिश करता हूं और प्रत्येक विस्तारित वर्ग पर @ एंटीटी एनोटेशन करता हूं, तो यह भेदभावकर्ता एनोटेशन होने पर भी भेदभावकर्ता प्रकार को खोने की शिकायत करता है।

+0

क्या यह सब जेनरेट (गतिशील) एसक्यूएल है? यदि नहीं तो आप सभी बाइबल को सिस्टम बाइंड में बदलने के लिए कर्सर_शियरिंग = फोर्स सेट कर सकते हैं। – sandman

+0

जबकि कर्सर_शियरिंग = फोर्स काम करेगा यदि यह ओरेकल है, जो आमतौर पर निराश होता है। उत्पादन में इसे लागू करने से पहले दो बार सोचो! – user2612030

+0

@ सैंडमैन ये गतिशील प्रश्न हैं और यह ओरेकल है, हम इसे किसी भी तरह से आगे बढ़ने जा रहे हैं। हालांकि, इनपुट के लिए धन्यवाद क्योंकि किसी को यह उपयोगी लगता है। – AHungerArtist

उत्तर

1

नहीं, बॉक्स से बाहर निकलना संभव नहीं है।

निकटतम वैकल्पिक हल है कि मेरे दिमाग में आता है आधार वर्ग से चुनने के लिए और स्पष्ट रूप से उपवर्ग के आधार पर फ़िल्टर है:

entityManager.createQuery("select gne from NamePartEntity gne where type(gne) = :subclass") 
    .setParameter("subclass", GivenNameEntity.class) 
    .getResultList(); 
0

वैकल्पिक रूप से, वहाँ एक रास्ता मैं अभी भी उपयोग किए बिना मेरी विस्तारित वर्गों का उपयोग कर सकते है भेदभाव मूल्य? तो मुझे लगता है कि कोशिश करते हैं और प्रत्येक विस्तारित वर्ग पर @Entity एनोटेशन है, यह discriminator प्रकार लापता के बारे में शिकायत, भले ही कोई discriminator एनोटेशन

InheritanceType.SINGLE_TABLE रणनीति आप का उपयोग किया है की वजह से है कि कर रहे हैं। आप अक्सर पूछे जाने वाले प्रश्नों के आधार पर InheritanceType.JOINED जैसी अन्य रणनीतियों का उपयोग करने का प्रयास कर सकते हैं।

एक और नोट पर, इस प्रकार के Names प्रति-से एक संकेतक नहीं है कि आपके पास एक संबंध के रूप में प्रकार होना चाहिए, न कि उप-प्रकार?

+0

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

+0

हां, अगर यह एक ही टेबल पर होगा तो 'जॉइनड' आपकी मदद नहीं करेगा। लेकिन, अगर यह सिर्फ एक ही कॉलम है तो यह मोटे तौर पर उस संपत्ति में अनुवाद करेगा जिसे 'NamePartEntity' की' टाइप' संपत्ति 'बनाया जा सकता है। जैसा कि आप कहते हैं कि जावा में अलग-अलग 'कक्षाएं' हो सकती हैं (आप पूरी तरह से कामना करते हैं), यदि प्रत्येक 'NamePartEntity' दूसरे से काफी अलग व्यवहार करता है, लेकिन उन्हें' संस्थाएं '(राज्य जानकारी) नहीं होनी चाहिए, तो वे बस हो सकते हैं 'कक्षाएं' (ओओ संरचना)। सिर्फ एक सुझाव है क्योंकि मेरे पास वास्तव में वह उत्तर नहीं है जिसे आप ढूंढ रहे हैं :) – anchreg

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