2012-11-28 7 views
8

मौलिक प्रश्न: @Embedded ऑब्जेक्ट्स हमेशा तत्काल क्यों नहीं हैं?@ एम्बेडेड ऑब्जेक्ट स्वचालित रूप से तत्काल नहीं होता है यदि उसके पास कोई मूल डेटाटाइप फ़ील्ड नहीं है

दिलचस्प अवलोकन यह है कि यदि ईबेन मूल डेटाटाइप (int, बूलियन ...) नहीं है या पहले स्पर्श नहीं किया गया है तो ईबेन @ एम्बेडेड ऑब्जेक्ट्स को तुरंत चालू नहीं करता है। उदाहरण:

@Entity 
public class Embedder { 
    // getNotAutoInstantiated() will return null if this field was not touched before 
    @Embedded 
    private NotAutoInstantiated notAutoInstantiated = new NotAutoInstantiated(); 
    // getAutoInstantiated() will always return an instance! 
    @Embedded 
    private AutoInstantiated autoInstantiated = new AutoInstantiated(); 
} 

@Embeddable 
public class AutoInstantiated { 
    // theKey is why this embedded object is always instantiated 
    private int theKey; 
    private String field1;  
} 

@Embeddable 
public class NotAutoInstantiated { 
    private String field2;  
} 
+0

आपको एकाधिक एम्बेडेड ऑब्जेक्ट्स के बीच फील्ड नाम टकराव के साथ समस्या हो सकती है। आम तौर पर, जेपीए प्रदाता एम्बेडेड ऑब्जेक्ट फ़ील्ड को मूल तालिका में कॉलम पर मानचित्र करता है। यदि एम्बेडेड फ़ील्ड नाम लंबे समय तक चलते हैं, तो आप डेटाबेस में छंटनी वाले फ़ील्ड नामों और कॉलम नामों में टकराव के साथ समाप्त हो सकते हैं। – Zagrev

+0

उदाहरण धोखा दे सकता है। मेरे कोड में नाम बहुत कम हैं और वे उसी उपसर्ग से शुरू नहीं होते हैं। लेकिन यहां तक ​​कि उदाहरण में फ़ील्ड "नहीं" और "ऑटो" से शुरू होते हैं, इसलिए छंटनी एक बड़ी समस्या नहीं होगी। – allprog

+0

वास्तव में, मैं "फ़ील्ड" और "फ़ील्ड" के बारे में सोच रहा था। – Zagrev

उत्तर

3

मुझे नहीं लगता कि जेपीए कल्पना स्पष्ट रूप से बताता है कि किसी @Embedded ऑब्जेक्ट के गुणों सभी अशक्त हैं जब कि क्या होने चाहिए, लेकिन कम से कम कुछ कार्यान्वयन एक अशक्त वस्तु, के रूप में अशक्त गुणों के साथ एक वस्तु का इलाज जो क्या आप देख रहे हैं

यह एक उचित कार्यान्वयन की तरह लगता है। निश्चित रूप से यह मेरे कोड (हाइबरनेट का उपयोग करके) में उपयोगी रहा है, जहां मैंने @Embedded ऑब्जेक्ट को शून्य पर सेट किया है, तो मैं एक निरंतर संस्करण लोड करते समय इसे शून्य रखना चाहता हूं।

आपके उदाहरण में, AutoInstantiated कक्षा को कभी भी शून्य नहीं माना जा सकता है, क्योंकि आदिम संपत्ति theKey कभी शून्य नहीं हो सकती है।

+0

दुर्भाग्यवश, स्थिति उससे भी बदतर है। ऐसा लगता है कि ईबेन इस व्यवहार के अनुरूप नहीं है। हमारे पास एक जटिल जटिल डेटा मॉडल है जहां अधिकांश स्थानों में ऑटोइंस्टैंटियेटेड-जैसे @ एम्बेड फ़ील्ड वास्तव में ऑटो तत्काल हो जाते हैं। लेकिन एक ऐसा स्थान है जहां ऐसा नहीं होता है।हम उस की विशिष्टता नहीं पा रहे थे। "इसे छोड़कर शून्य" दृष्टिकोण मेरे लिए सबसे अच्छा नहीं है क्योंकि इसे एक और शून्य जांच की आवश्यकता है। जावा में यह सबसे खराब प्रथा है। इस तरह के मामलों में आसानी से बचा जा सकता है ... – allprog

3

आप जाँच करना चाहते हो सकता है:

https://hibernate.atlassian.net/browse/HHH-7610

विशेष रूप से, 5.1 के बाद से:

static final String CREATE_EMPTY_COMPOSITES_ENABLED 

Enable instantiation of composite/embedded objects when all of its 
attribute values are null. The default (and historical) behavior is that a null reference 
will be used to represent the composite when all of its attributes are null 
@since 5.1 
@see Constant Field Values 

सच और देखा करने के लिए hibernate.create_empty_composites.enabled प्रॉपर्टी सेट!

+0

धन्यवाद, यह जानना अच्छा है। हालांकि, सवाल ईबीन से संबंधित है। हाइबरनेट शायद कई पहलुओं में बेहतर है, लेकिन ईबीन छोटी परियोजनाओं के साथ बेहतर फिट बैठता है। – allprog

1

मैंने अभी ही हाइबरनेट के साथ एक ही समस्या को मारा। मूल प्रश्न, "क्यों" के बारे में उत्तर दिया गया है।

लेकिन एक समाधान के बारे में बात करने के लिए, मैं सिर्फ वर्ग के भीतर एक विधि का उपयोग @PostLoad, तो embedder कुछ की तरह:

@PostLoad 
private void initData() { 
    if(notAutoInstantiated == null) { 
    notAutoInstantiated = new NotAutoInstantiated(); 
    } 
} 

अद्यतन:

चेतावनी! ऊपरी कोड काम कर रहा है, लेकिन एक अप्रत्याशित दुष्प्रभाव है! जैसे ही आप डेटाबेस से नल पॉइंटर के साथ अपनी ऑब्जेक्ट लोड करते हैं, इस पोस्ट लोड कोड के कारण इसे गंदे के रूप में चिह्नित किया जाता है! मेरे मामले में, यह दुष्प्रभाव थ्रेड से SQL अद्यतन कमांड की ओर जाता है, जो केवल इस बग को खोजने के डेटा और घंटे लोड करना चाहिए!

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

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