2012-01-23 11 views
62

क्या वे खुशी से विवाहित हैं?हाइबरनेट 4 और जोडा-टाइम

मैं हाइबरनेट (4) के नवीनतम संस्करण और joda-time hibernate support के संस्करण 1.3 का उपयोग कर रहा हूं, जिसे मैं वर्तमान नवीनतम रिलीज मानता हूं।

@Column 
@Type(type="org.joda.time.contrib.hibernate.PersistentLocalDate") 
private LocalDate myDate; 

उनके इन संस्करणों को एक साथ उपयोग करने के साथ किसी भी ज्ञात समस्याओं कर रहे हैं:

सब कुछ जब टिप्पणियों का उपयोग करने के लिए ठीक (तारीख की उम्मीद के रूप में बनाया कॉलम) काम कर रहा है?

अद्यतन खैर पता चला कॉलम बनाया हो, लेकिन किसी भी डेटा के साथ पॉप्युलेट करने में असमर्थ:

हैंडलर संसाधन विफल; नेस्टेड अपवाद java.lang.AbstractMethodError है: org.joda.time.contrib.hibernate.PersistentLocalDateTime.nullSafeSet

वे असंगत हैं, और मैं usertype का उपयोग करना चाहिए। नीचे उत्तर देखें।

+0

आपने अभी हमें बताया है कि उन्होंने * एक साथ काम किया है, है ना? – skaffman

+0

@ स्काफमैन मैंने कॉलम निर्माण के अलावा किसी अन्य चीज का परीक्षण नहीं किया है ... यह मेरी समझ थी कि पिछले संस्करण (जोडा-टाइम lib का) को हाइबरनेट के नए संस्करण के खिलाफ पुनः संयोजित किया जाना था। यह एक अलार्म था - इसलिए सवाल ... – NimChimpsky

+0

वे खुशी से शादी नहीं कर रहे हैं, हाइबरनेट में अन्य रिश्ते हैं ... और जोडा ..:/.. वह चोट पहुंची है – nobalG

उत्तर

96

दस्तावेज़ीकरण की एक अलग कमी, मतलब है कि मेरे लिए एकीकरण के लिए आवश्यक चरणों को लिखना उपयोगी हो सकता है। सुनिश्चित करें कि आपके पुस्तकालय अद्यतित हैं।

आप की आवश्यकता होगी: [यह सोचते हैं आप पहले से ही hibernate4 है]

Joda समय का नवीनतम संस्करण

<dependency> 
    <groupId>joda-time</groupId> 
    <artifactId>joda-time</artifactId> 
    <version>2.0</version> 
</dependency> 

और प्रयोक्ता प्रकार lib

<dependency> 
    <groupId>org.jadira.usertype</groupId> 
    <artifactId>usertype.core</artifactId> 
    <version>3.0.0.CR1</version> 
</dependency> 

तब इकाई कक्षाओं में निम्नलिखित का उपयोग (स्थानीयडेटाइम होना आवश्यक नहीं है, उपलब्ध किसी भी कक्षा में उपलब्ध हो सकता है):

import org.joda.time.LocalDateTime; 

और स्तंभ परिभाषा के लिए:

@Column(name="updated", nullable = false) 
@Type(type="org.jadira.usertype.dateandtime.joda.PersistentLocalDateTime") 
private LocalDateTime updated; 
+1

हम कैसे जानते हैं कि यह हमारे पसंद के डेटाबेस में किस प्रकार का नक्शा है? – benstpierre

+0

@ बेंजू ने इसके निर्माण के बाद डेटाबेस टेबल पर एक नज़र डाली है ... – NimChimpsky

+0

दाएं, तो टेबल की ऑटो पीढ़ी का उपयोग करें और आउटपुट देखें? – benstpierre

29

मैं इस एक अलग जवाब के रूप में के बाद से यह मेरी राय में महत्वपूर्ण जानकारी में है हाइबरनेट करने के लिए 4 उन्नयन किसी के लिए भी जोड़ देंगे, और जरूरत में jadira के लगातार अस्थायी प्रकार का उपयोग करने के लिए पलायन की । यह पृष्ठ हाइबरनेट 4 और जोडाटाइम के लिए Google खोज परिणामों में अत्यधिक रैंक है, इसलिए मैं इसे यहां जोड़ दूंगा। (इस मुद्दे की एक अलग चर्चा के लिए, देखें: Joda time DateTime incorrectly stores in database)

यदि आप यूटीसी के अलावा एक समय क्षेत्र में हैं, तो वही व्यवहार प्राप्त करने के लिए कॉन्फ़िगरेशन का एक महत्वपूर्ण टुकड़ा आवश्यक है जैसे आप जोडा-टाइम हाइबरनेट के साथ करेंगे -support प्रकार। जिस तरह से जादिरा के अस्थायी प्रकार डिफ़ॉल्ट रूप से काम करते हैं, डेटाबेस से पहले सभी मानों को यूटीसी टाइमज़ोन में परिवर्तित करने और डेटाबेस से मूल्यों को लोड करते समय सिस्टम के टाइमज़ोन में कनवर्ट करने के माध्यम से होता है।

मुझे अपग्रेड करने के बाद इसे जला दिया गया, जब मेरे पास डेटाबेस में मेरे सटीक टाइमज़ोन (यूटीसी + 1 (+2 गर्मियों में) के साथ बहुत सी टाइमस्टैम्प थीं। जब हाइबरनेट 4, 1 या 2 घंटों तक अपग्रेड करने के बाद लोड किया जाता है (ग्रीष्मकालीन समय के दौरान टाइमस्टैम्प था या नहीं) डेटाबेस में मूल्य में जोड़ा गया था, जिसका मतलब था कि सभी मौजूदा टाइमस्टैम्प गलती से प्रस्तुत किए गए थे। इसके अलावा, यूटीसी टाइमज़ोन के साथ डेटाबेस में नए टाइमस्टैम्प मान संग्रहीत किए गए थे, जिससे उन्हें एप्लिकेशन में सही तरीके से दिखाई देने के लिए प्रेरित किया गया था, लेकिन डेटाबेस में गलत था।सब कुछ, टाइमज़ोन और टाइमस्टैम्प की एक गर्म गड़बड़।

तो, जोडा-टाइम्स हाइबरनेट-सपोर्ट के साथ समान व्यवहार प्राप्त करने के लिए (डेटाटाइम को प्रश्न में सर्वर के टाइमज़ोन के रूप में जारी रखा जा रहा है, और डेटाबेस में टाइमस्टैम्प लोड होने के समान ही हैं आवेदन में), निम्नलिखित गुण जेपीए/हाइबरनेट विन्यास के लिए (मेरे मामले में, जोड़ा जाना चाहिए hibernate.properties):

jadira.usertype.autoRegisterUserTypes=true 
jadira.usertype.databaseZone=jvm 
jadira.usertype.javaZone=jvm 

यह सुनिश्चित करें कि डेटाबेस में टाइमस्टैम्प रूप में एक ही समय क्षेत्र का हो जाएगा कर देगा आवेदन की, जो बदले में जेवीएम का समय क्षेत्र होगा (ज्यादातर मामलों में एप्लिकेशन सर्वर की घड़ी)।

इसके अलावा

, autoRegisterUserTypes -property, से मैं क्या समझ आम प्रकार, उन के बीच Jodatime-प्रकार DateTime और LocalDate के चयन के लिए @Type -annotation के लिए की जरूरत को हटा।

+2

चूंकि आपने अपनी समस्या हल कर ली है, और यह सीधे इस प्रश्न से संबंधित नहीं था, मैं अपनी टिप्पणियों को हटा दूंगा और हटाने के लिए आपका निशान चिह्नित करूंगा, इसलिए हम टिप्पणी अनुभाग को साफ और बिंदु पर रखते हैं। – Tobb

+0

बस एक प्रश्न अलग: यूटीसी समय में हर टाइमस्टैम्प क्यों स्टोर नहीं करते? क्या होगा यदि सर्वर एक अलग समय क्षेत्र में चला जाता है? इम्हो यूटीसी समय में सभी टाइमस्टैम्प स्टोर करना सबसे अच्छा होगा और ग्राहक को यह तय करने दें कि वह किस समय क्षेत्र में है। – displayname

+0

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

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