Celesta 7.x: ORM, माइग्रेशन और परीक्षण "एक पैकेज में"

शायद आप पहले से ही खुले स्रोत Celesta पुस्तकालय के बारे में कुछ जानते हैं। यदि नहीं, तो कोई बात नहीं, अब हम आपको सब कुछ बताएंगे। एक और साल बीत गया, संस्करण 7.x जारी किया गया था, बहुत सारी चीजें बदल गई थीं, और यह परिवर्तनों को संक्षेप में प्रस्तुत करने का समय था, और साथ ही यह याद दिलाने के लिए कि सामान्य तौर पर सेलेस्टा क्या है।

यदि आपने अभी तक Celesta के बारे में कुछ भी नहीं सुना है, और इस लेख को पढ़ते समय, आप यह जानना चाहते हैं कि इसके लिए कौन से व्यावसायिक कार्य सबसे प्रभावी हैं, तो मैं पुराने पोस्ट के पहले भाग या इस आधे घंटे के वीडियो (पायथन भाषा का उपयोग करने के बारे में शब्दों को छोड़कर) की सिफारिश कर सकता हूं। लेकिन बेहतर अभी भी, इस लेख को पहले पढ़ें। मैं संस्करण 7 में हुए परिवर्तनों के साथ शुरू करूंगा, और फिर मैं स्प्रिंग बूट का उपयोग करके जावा एप्लिकेशन के लिए एक छोटा बैकेंड सेवा लिखने के लिए सेलेस्टा के आधुनिक संस्करण का उपयोग करने का एक पूरा तकनीकी उदाहरण लूंगा।

संस्करण 7.x में क्या बदलाव आया है?

1. हमने जेथॉन को सेलेस्टा में निर्मित भाषा के रूप में उपयोग करने से इनकार कर दिया। अगर पहले हमने सेलस्टा के बारे में इस तथ्य के बारे में बात करना शुरू कर दिया कि व्यावसायिक तर्क पायथन में लिखा गया है, तो अब ... कोई भी जावा भाषा व्यावसायिक तर्क की भाषा के रूप में काम कर सकती है: जावा, ग्रूवी, आरयूबी या वही जाइथन। अब Celesta व्यवसाय तर्क कोड को कॉल नहीं करता है, लेकिन व्यवसाय तर्क कोड Celesta और उसके डेटा एक्सेस कक्षाओं को सबसे आम जावा लाइब्रेरी के रूप में उपयोग करता है। हां, इस वजह से पिछड़े संगतता का उल्लंघन किया गया था, लेकिन यह वह कीमत है जिसे हम देने को तैयार थे। दुर्भाग्य से, Jython पर हमारा दांव हार गया। जब हमने कुछ साल पहले जाइथन का उपयोग करना शुरू किया था, तो यह एक जीवंत और आशाजनक परियोजना थी, लेकिन वर्षों में इसका विकास धीमा हो गया, भाषा विनिर्देशन से बैकलॉग जमा हो गया, अधिकांश पाइप पुस्तकालयों के लिए संगतता समस्याओं का समाधान नहीं हुआ। अंतिम भूसा नवीनतम भाषा रिलीज में नए कीड़े थे, जो उत्पादन भार पर काम करते समय खुद को प्रकट करते थे। हमारे पास जाइथन परियोजना का समर्थन करने के लिए संसाधन नहीं हैं, और हमने इसके साथ भागीदारी करने का निर्णय लिया। Celesta अब Jython पर निर्भर नहीं है।
2. डेटा एक्सेस क्लासेस अब जावा लैंग्वेज (और पहले की तरह पाइथन नहीं) में मावेन प्लगइन का उपयोग करके कोड-जनरेट किए जाते हैं। और चूँकि हम डायनेमिक टाइपिंग से स्थिर टाइपिंग की ओर चले गए थे, इस वजह से इसमें रिफैक्टरिंग के अधिक अवसर थे और विषयवार सही कोड लिखना आसान हो गया।
3. JUnit5 के लिए एक्सटेंशन दिखाई दिया, इसलिए JUnit5 में डेटाबेस के साथ काम करने वाले तर्क के परीक्षण लिखना बहुत सुविधाजनक हो गया (जिस पर बाद में चर्चा की जाएगी)।
4. एक अलग परियोजना दिखाई दी है - स्प्रिंग-बूट-स्टार्टर-सेलेस्टा , जो, जैसा कि नाम से पता चलता है, स्प्रिंग बूट में सेलेस्टा स्टार्टर है। आसानी से परिनियोजित स्प्रिंग बूट सेवाओं में सेलेस्टा अनुप्रयोगों को पैक करने की क्षमता ने पायथन स्क्रिप्ट के साथ फ़ोल्डर को बदलकर सर्वर पर एप्लिकेशन को अपडेट करने की क्षमता के नुकसान के लिए मुआवजा दिया।
5. हमने विकी से लेकर असिसीडॉक्टर प्रारूप में सभी दस्तावेज स्थानांतरित कर दिए , इसे कोड के साथ संस्करण नियंत्रण में रखा, और अब हमारे पास प्रत्येक सेलेस्टा रिलीज के लिए अप-टू-डेट प्रलेखन है। नवीनतम रिलीज़ के लिए, ऑनलाइन दस्तावेज़ यहाँ उपलब्ध है: https://courseorchestra.imtqy.com/celesta/
6. हमसे अक्सर पूछा जाता था कि क्या सेलेस्टा से अलग डीडीएमएल के माध्यम से डेटाबेस माइग्रेशन का उपयोग करना संभव है। अब 2bass टूल का उपयोग करने का ऐसा अवसर है।

सेलेस्टा क्या है और वह क्या कर सकती है?

संक्षेप में, सेलेस्टा है:

• डेटाबेस-प्रथम डिज़ाइन दृष्टिकोण के आधार पर रिलेशनल डेटाबेस और व्यावसायिक तर्क कोड के बीच एक मध्यवर्ती परत,
• डेटाबेस संरचना प्रवासन तंत्र,
• डेटा के साथ काम करने वाले परीक्षण कोड की रूपरेखा।

हम चार प्रकार के रिलेशनल डेटाबेस का समर्थन करते हैं: PostgreSQL, MS SQL सर्वर, Oracle और H2।

सेलेस्टा की मुख्य विशेषताएं:

1. जावा के मूल सिद्धांत के समान एक सिद्धांत: "एक बार लिखें, प्रत्येक समर्थित आरडीबीएमएस पर चलाएं।" व्यापार तर्क कोड को पता नहीं है कि यह किस प्रकार के डेटाबेस पर चलेगा। आप व्यवसाय तर्क कोड लिख सकते हैं और इसे MS SQL सर्वर में चला सकते हैं, फिर PostgreSQL पर स्विच कर सकते हैं, और यह जटिलताओं के बिना होगा (अच्छी तरह से, लगभग :)
2. लाइव डेटाबेस पर स्वचालित पुनर्गठन। सेलेस्टा-परियोजनाओं का अधिकांश जीवन चक्र तब होता है जब कार्यशील डेटाबेस पहले से ही होता है और यह ऐसे डेटा से भरा होता है जिन्हें सहेजने की आवश्यकता होती है, लेकिन उनकी संरचना को लगातार बदलना भी आवश्यक है। सेलेस्टा की प्रमुख विशेषताओं में से एक आपके डेटा मॉडल में डेटाबेस संरचना को स्वचालित रूप से "फिट" करने की क्षमता है।
3. परीक्षण। यह सुनिश्चित करने के लिए बहुत ध्यान दिया जाता है कि सेलेस्टा के लिए कोड परीक्षण योग्य है, ताकि हम डेटाबेस में डेटा को संशोधित करने वाले तरीकों को स्वचालित रूप से परीक्षण कर सकें, यह आसानी से, जल्दी और सुरुचिपूर्ण ढंग से कर रहे हैं, बाहरी उपकरणों जैसे कि डबनेट और कंटेनरों का उपयोग किए बिना।

आपको डीबीएमएस के प्रकार से स्वतंत्रता की आवश्यकता क्यों है?

DBMS के प्रकार से व्यावसायिक लॉजिक कोड की स्वतंत्रता हम पहले बिंदु नहीं थे: सेलेस्टा के लिए लिखे गए कोड को यह नहीं पता है कि यह किस DBMS पर चल रहा है। क्यों?

सबसे पहले, इस तथ्य के कारण कि डीबीएमएस प्रकार की पसंद एक तकनीकी मुद्दा नहीं है, लेकिन एक राजनीतिक है। एक नए व्यापार ग्राहक के लिए आ रहा है, हम अक्सर पाते हैं कि उसके पास पहले से ही पसंदीदा प्रकार का DBMS है जिसमें धन का निवेश किया जाता है, और ग्राहक मौजूदा बुनियादी ढांचे पर अन्य समाधान देखना चाहता है। तकनीकी परिदृश्य बदल रहा है: PostgreSQL तेजी से सरकारी एजेंसियों और निजी कंपनियों में पाया जाता है, हालांकि कुछ समय पहले एमएस एसक्यूएल सर्वर हमारे व्यवहार में प्रबल था। सेलेस्टा सबसे आम DBMSs का समर्थन करता है, और हम इन परिवर्तनों के बारे में चिंतित नहीं हैं।

दूसरे, मैं पुन: प्रयोज्य पुस्तकालय बनाने के लिए एक परियोजना से दूसरी में मानक समस्याओं को हल करने के लिए पहले से बनाए गए कोड को स्थानांतरित करना चाहूंगा। पदानुक्रमित निर्देशिका या ईमेल अधिसूचना वितरण मॉड्यूल जैसी चीजें स्वाभाविक रूप से मानक हैं, और हमें विभिन्न संबंधों वाले ग्राहकों के लिए कई संस्करणों का समर्थन करने की आवश्यकता क्यों है?

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

CelestaSQL

क्रॉस-बेसमेंटवाद कैसे प्राप्त किया जाता है? बेशक, केवल एक विशेष एपीआई के माध्यम से डेटा के साथ काम करने की कीमत पर जो तर्क को किसी भी डेटाबेस से निर्दिष्ट करता है। सेलेस्टा एक तरफ डेटा तक पहुँचने के लिए जावा कक्षाएं बनाता है, और दूसरी ओर SQL कोड और डेटाबेस के अंदर कुछ सहायक वस्तुएं।

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

आप केवल समर्थित कार्यक्षमता के लिए सभी समर्थित DBMS पर समान कार्य प्राप्त कर सकते हैं जो उनमें से प्रत्येक में लगभग समान रूप से लागू किया गया है। यदि हम सशर्त रूप से "यूलर सर्कल" के रूप में हमारे द्वारा समर्थित आधारों में से प्रत्येक की कार्यात्मक क्षमताओं के सेट को चित्रित करते हैं, तो हमें निम्नलिखित चित्र मिलते हैं:

यदि हम डेटाबेस के प्रकार से पूर्ण स्वतंत्रता प्रदान करते हैं, तो जो कार्यक्षमता हम व्यावसायिक तर्क प्रोग्रामर के लिए खोलते हैं, उसे सभी ठिकानों के चौराहे के अंदर रखना चाहिए। पहली नज़र में, ऐसा लगता है कि यह एक महत्वपूर्ण सीमा है। हां: कुछ विशिष्ट विशेषताएं, उदाहरण के लिए, हम SQL सर्वर का उपयोग नहीं कर सकते हैं। लेकिन अपवाद के बिना, रिलेशनल डेटाबेस टेबल, विदेशी कुंजी, विचार, अनुक्रम, जॉइन और ग्रुप बाय के साथ एसक्यूएल प्रश्नों का समर्थन करते हैं। तदनुसार, हम डेवलपर्स को ये अवसर दे सकते हैं। हम डेवलपर्स को "प्रतिरूपित SQL" प्रदान करते हैं, जिसे हम "CelestaSQL" कहते हैं, और इस प्रक्रिया में हम संबंधित डेटाबेस की बोलियों के लिए SQL क्वेरी उत्पन्न करते हैं।

CelestaSQL भाषा में डेटाबेस ऑब्जेक्ट्स को परिभाषित करने और विचारों और फ़िल्टर के लिए सेलेक्ट क्वेरीज़ के लिए DDL शामिल है, लेकिन इसमें DML कमांड शामिल नहीं हैं: डेटा को संशोधित करने के लिए कर्सर का उपयोग किया जाता है, जिन पर अभी भी चर्चा की जानी है।

प्रत्येक डेटाबेस में डेटा प्रकारों का अपना सेट होता है। CelestaSQL के अपने प्रकार के सेट भी हैं। लेखन के समय, उनमें से नौ हैं, और यह तालिका विभिन्न डेटाबेस और जावा डेटा प्रकारों में वास्तविक प्रकारों के साथ उनकी तुलना करती है।

ऐसा लग सकता है कि नौ प्रकार के लिए पर्याप्त नहीं है (उदाहरण के लिए, PostgreSQL का समर्थन करता है ) की तुलना में, लेकिन वास्तव में ये ऐसे प्रकार हैं जो वित्तीय, व्यापार और लॉजिस्टिक जानकारी को संग्रहीत करने के लिए पर्याप्त हैं: तार, पूर्णांक, आंशिक इस तरह के डेटा का प्रतिनिधित्व करने के लिए, दिनांक, बूलियन मान और ब्लब हमेशा पर्याप्त होते हैं।

CelestaSQL भाषा को स्वयं प्रलेखन में बड़ी संख्या में सिंटैक्स आरेखों के साथ वर्णित किया गया है।

डेटाबेस संरचना का संशोधन। बेरोजगार डीडीएल

सेलेस्टा की एक अन्य प्रमुख विशेषता परियोजना के विकास के रूप में कार्यशील डेटाबेस की संरचना को स्थानांतरित करने के लिए इसका दृष्टिकोण है। ऐसा करने के लिए, idempotent DDL का उपयोग करते हुए सेलेस्टा में निर्मित दृष्टिकोण का उपयोग किया जाता है।

संक्षेप में, जब हम CelestaSQL में निम्नलिखित पाठ लिखते हैं:

CREATE TABLE OrderLine( order_id VARCHAR(30) NOT NULL, line_no INT NOT NULL, item_id VARCHAR(30) NOT NULL, item_name VARCHAR(100), qty INT NOT NULL DEFAULT 0, cost REAL NOT NULL DEFAULT 0.0, CONSTRAINT Idx_OrderLine PRIMARY KEY (order_id, line_no) ); 

- इस पाठ को सेलेस्टा द्वारा "एक तालिका बनाने के रूप में व्याख्या नहीं की गई है, लेकिन अगर पहले से ही एक तालिका है, तो एक त्रुटि दें", लेकिन "वांछित संरचना में तालिका लाएं"। वह यह है: “यदि कोई तालिका नहीं है, तो इसे बनाएं, यदि कोई तालिका है, तो देखें कि इसमें कौन से फ़ील्ड हैं, किस प्रकार के हैं, कौन से अनुक्रमित हैं, कौन सी विदेशी कुंजियाँ हैं, क्या डिफ़ॉल्ट मान हैं, आदि, और क्या इसमें कुछ बदलना आवश्यक है। इस तालिका को सही तरह से लाने के लिए। ”

इस दृष्टिकोण के साथ, हम डेटाबेस की संरचना को निर्धारित करने के लिए रिफलेक्टर और संस्करण नियंत्रण स्क्रिप्ट की क्षमता को लागू करते हैं:

• हम स्क्रिप्ट में संरचना की वर्तमान "वांछित छवि" देखते हैं,
• क्या, किसके द्वारा और क्यों संरचना समय के साथ बदल गई है, हम संस्करण नियंत्रण प्रणाली के माध्यम से देख सकते हैं,
• ALTER कमांड के लिए, सेलेस्टा स्वचालित रूप से आवश्यक के रूप में "हुड के तहत" उत्पन्न और निष्पादित करता है।

बेशक, इस दृष्टिकोण की अपनी सीमाएं हैं। सेलेस्टा यह सुनिश्चित करने के लिए हर संभव प्रयास करता है कि स्वचालित प्रवास दर्द रहित और निर्बाध हो, लेकिन यह सभी मामलों में संभव नहीं है। इस दृष्टिकोण की प्रेरणा, संभावनाएं और सीमाएं इस पोस्ट में उल्लिखित थीं (इसका अंग्रेजी संस्करण भी उपलब्ध है)।

डेटाबेस संरचना की जाँच / अद्यतन करने की प्रक्रिया को तेज करने के लिए, Celesta डेटाबेस में DDL स्क्रिप्ट चेकसम के भंडारण को लागू करता है (जब तक कि चेकसम को बदल नहीं दिया जाता है, डेटाबेस संरचना की जाँच और अद्यतन करने की प्रक्रिया शुरू नहीं होती है)। एक दूसरे पर निर्भर वस्तुओं के परिवर्तन के क्रम से संबंधित समस्याओं के बिना आगे बढ़ने के लिए अद्यतन प्रक्रिया के लिए, विदेशी कुंजियों द्वारा योजनाओं के बीच निर्भरता के सामयिक छंटाई को लागू किया जाता है। स्वचालित माइग्रेशन प्रक्रिया को प्रलेखन में अधिक विस्तार से वर्णित किया गया है ।

एक सेलेस्टा परियोजना और डेटा मॉडल बनाना

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

• org.springframework.boot:spring-boot-starter-web और ru.curs:spring-boot-starter-celesta (अधिक जानकारी के लिए, दस्तावेज़ ru.curs:spring-boot-starter-celesta )।
• यदि आप स्प्रिंग बूट का उपयोग नहीं कर रहे हैं, तो आप ru.curs:celesta-system-services को कनेक्ट कर सकते हैं ru.curs:celesta-system-services निर्भरता सीधे।
• ru.curs:celesta-maven-plugin -एसक्यूएल स्क्रिप्ट के आधार पर डेटा एक्सेस कक्षाओं की कोड पीढ़ी के लिए, ru.curs:celesta-maven-plugin आवश्यकता है ru.curs:celesta-maven-plugin - एक डेमो उदाहरण या प्रलेखन के लिए स्रोत कोड बताता है कि इसे कैसे कनेक्ट किया जाए।
• डेटा को संशोधित करने वाले तरीकों के लिए JUnit5 इकाई परीक्षणों को लिखने की क्षमता का लाभ उठाने के लिए, आपको ru.curs:celesta-unit को कनेक्ट करना होगा ru.curs:celesta-unit परीक्षण के दायरे में ru.curs:celesta-unit ।

अब एक डेटा मॉडल बनाएं और डेटा एक्सेस कक्षाओं को संकलित करें।

मान लीजिए कि हम एक ई-कॉमर्स कंपनी के लिए एक प्रोजेक्ट कर रहे हैं, जिसका हाल ही में दूसरी कंपनी में विलय हुआ है। प्रत्येक का अपना डेटाबेस है। वे आदेश एकत्र करते हैं, लेकिन जब तक वे अपने डेटाबेस को विलय नहीं करते, तब तक उन्हें बाहर से आदेश एकत्र करने के लिए एक एकल प्रवेश बिंदु की आवश्यकता होती है।

इस "प्रवेश बिंदु" का कार्यान्वयन काफी पारंपरिक होना चाहिए: CRUD संचालन के साथ एक HTTP सेवा जो एक संबंधपरक डेटाबेस में डेटा संग्रहीत करती है।

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

तो, नौकरी के लिए: बनाएँ

• src/main/celestasql - डिफ़ॉल्ट रूप से, यह CelestaSQL प्रोजेक्ट स्क्रिप्ट का पथ है
• इसमें सबफ़ोल्डर्स शामिल हैं जो जावा पैकेज (हमारे मामले में ru/curs/demo ) की फ़ोल्डर संरचना को दोहराते हैं।
• पैकेज फ़ोल्डर में, निम्न सामग्री के साथ एक .sql फ़ाइल बनाएँ:

 CREATE SCHEMA demo VERSION '1.0'; /** */ CREATE TABLE OrderHeader( id VARCHAR(30) NOT NULL, date DATETIME, customer_id VARCHAR(30), /**  */ customer_name VARCHAR(50), manager_id VARCHAR(30), CONSTRAINT Pk_OrderHeader PRIMARY KEY (id) ); /** */ CREATE TABLE OrderLine( order_id VARCHAR(30) NOT NULL, line_no INT NOT NULL, item_id VARCHAR(30) NOT NULL, item_name VARCHAR(100), qty INT NOT NULL DEFAULT 0, cost REAL NOT NULL DEFAULT 0.0, CONSTRAINT Idx_OrderLine PRIMARY KEY (order_id, line_no) ); ALTER TABLE OrderLine ADD CONSTRAINT fk_OrderLine FOREIGN KEY (order_id) REFERENCES OrderHeader(id); CREATE VIEW OrderedQty AS SELECT item_id, sum(qty) AS qty FROM OrderLine GROUP BY item_id; 

यहां हमने एक विदेशी कुंजी से जुड़ी दो तालिकाओं का वर्णन किया है, और एक दृश्य जो सभी ऑर्डर में मौजूद सामानों के लिए एक सारांश मात्रा लौटाएगा। जैसा कि आप देख सकते हैं, यह CREATE SCHEMA स्कीमा कमांड के अपवाद के साथ, नियमित एसक्यूएल से अलग नहीं है, जिसमें हमने demo स्कीमा संस्करण घोषित किया था (कैसे संस्करण संख्या स्वत: माइग्रेशन को प्रभावित करती है, प्रलेखन देखें)। लेकिन इसकी विशेषताएं भी हैं। उदाहरण के लिए, हमारे द्वारा उपयोग किए जाने वाले तालिकाओं और क्षेत्रों के सभी नाम केवल ऐसे हो सकते हैं, जिन्हें जावा भाषा में मान्य वर्ग और चर नामों में बदला जा सकता है। इसलिए, रिक्त स्थान, विशेष वर्णों को बाहर रखा गया है। आप यह भी देख सकते हैं कि जो टिप्पणियां हमने तालिकाओं और कुछ क्षेत्रों के नाम पर रखी थीं, हम हमेशा की तरह / * से शुरू नहीं हुए, लेकिन / ** के साथ, कैसे JavaDoc टिप्पणियाँ शुरू होती हैं - और यह कोई दुर्घटना नहीं है! / ** से शुरू होने वाली इकाई पर परिभाषित एक टिप्पणी उस इकाई के .getCelestaDoc() संपत्ति में रनटाइम पर उपलब्ध होगी। यह उपयोगी है जब हम अतिरिक्त मेटा-जानकारी के साथ डेटाबेस तत्व प्रदान करना चाहते हैं: उदाहरण के लिए, मानव पठनीय फ़ील्ड नाम, उपयोगकर्ता इंटरफ़ेस में फ़ील्ड का प्रतिनिधित्व कैसे करें आदि के बारे में जानकारी।

CelestaSQL स्क्रिप्ट दो समान रूप से महत्वपूर्ण कार्य करती है: पहला, रिलेशनल डेटाबेस की संरचना के परिनियोजन / संशोधन के लिए और दूसरा, डेटा एक्सेस क्लासेस की कोड जनरेशन के लिए।

हम अभी डेटा एक्सेस क्लासेस जेनरेट कर सकते हैं, बस mvn generate-sources कमांड चला सकते हैं या, अगर आप IDEA में काम कर रहे हैं, तो मावेन कंट्रोल पैनल में 'जेनरेट सोर्स एंड फोल्डर्स फोल्डर' बटन पर क्लिक करें। दूसरे मामले में, IDEA target/generated-sources/celesta में बनाए target/generated-sources/celesta फ़ोल्डर को " target/generated-sources/celesta और परियोजना स्रोत कोड में आयात के लिए अपनी सामग्री उपलब्ध कराता है। कोड पीढ़ी का परिणाम निम्नानुसार होगा - डेटाबेस में प्रत्येक ऑब्जेक्ट के लिए एक वर्ग:

डेटाबेस का कनेक्शन एप्लिकेशन सेटिंग्स में, हमारे मामले में, src/main/resources/application.yml फ़ाइल में निर्दिष्ट है। स्प्रिंग-बूट-स्टार्टर-सेलेस्टा का उपयोग करते समय, IDEA आपको कोड पूरा करने में उपलब्ध कोड विकल्प बताएगा।

यदि हम प्रदर्शन उद्देश्यों के लिए "वास्तविक" RDBMS से परेशान नहीं करना चाहते हैं, तो हम निम्नलिखित कॉन्फ़िगरेशन का उपयोग करके इन-मेमोरी मोड में अंतर्निहित H2 डेटाबेस के साथ काम करने के लिए Celesta प्राप्त कर सकते हैं:

 celesta: h2: inMemory: true 

"वास्तविक" डेटाबेस से कनेक्ट करने के लिए, कॉन्फ़िगरेशन को कुछ इस तरह से बदलें

 celesta: jdbc: url: jdbc:postgresql://127.0.0.1:5432/celesta username: <your_username> password: <your_password> 

(इस मामले में, आपको मावेन निर्भरता के माध्यम से अपने आवेदन में PostgreSQL JDBC ड्राइवर भी जोड़ना होगा)।

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

डेटा हेरफेर के तरीके बनाना

एक बार जब आपको पता चल गया कि डेटाबेस संरचना कैसे बनाई जाए, तो आप व्यावसायिक तर्क लिखना शुरू कर सकते हैं।

एक्सेस अधिकारों को वितरित करने और लॉगिंग क्रियाओं के लिए आवश्यकताओं को लागू करने में सक्षम होने के लिए, Celesta में डेटा पर कोई भी ऑपरेशन उपयोगकर्ता की ओर से किया जाता है, कोई "अनाम" ऑपरेशन नहीं हैं। इसलिए, किसी भी Celesta कोड को CallContext वर्ग में वर्णित कॉल के संदर्भ में निष्पादित किया जाता है ।

• एक ऑपरेशन शुरू करने से पहले जो डेटाबेस में डेटा को संशोधित कर सकता है, CallContext सक्रिय है।
• सक्रियण के समय, कनेक्शन पूल से डेटाबेस का एक कनेक्शन लिया जाता है और लेनदेन शुरू होता है।
• ऑपरेशन CallContext होने के बाद CallContext या तो commit() निष्पादित करता है CallContext यदि ऑपरेशन सफल रहा था, या rollback() यदि निष्पादन के दौरान कोई अखंड अपवाद हुआ, तो CallContext बंद हो जाता है और डेटाबेस कनेक्शन पूल में वापस आ जाता है।

यदि हम स्प्रिंग-बूट-स्टार्टर-सेलेस्टा का उपयोग करते हैं, तो ये क्रियाएं @CelestaTransaction द्वारा एनोटेट किए गए सभी तरीकों के लिए स्वचालित रूप से की @CelestaTransaction ।

मान लीजिए हम एक हैंडलर लिखना चाहते हैं जो डेटाबेस को दस्तावेज़ बचाता है। इसका नियंत्रक-स्तर कोड इस तरह दिख सकता है:

 @RestController @RequestMapping("/api") public class DocumentController { private final DocumentService srv; public DocumentController(DocumentService srv) { this.srv = srv; } @PutMapping("/save") public void saveOrder(@RequestBody OrderDto order) { CallContext ctx = new CallContext("user1"); //new SystemCallContext(); srv.postOrder(ctx, order); } 

एक नियम के रूप में, नियंत्रक विधि के स्तर पर (यानी, जब प्रमाणीकरण पहले ही बीत चुका है), हम उपयोगकर्ता आईडी को जानते हैं और CallContext बनाते समय इसका उपयोग कर सकते हैं। किसी उपयोगकर्ता को किसी संदर्भ में बाँधना तालिकाओं तक पहुँचने की अनुमति निर्धारित करता है, और उसकी ओर से किए गए परिवर्तनों को लॉग करने की क्षमता भी प्रदान करता है। सच है, इस मामले में, डेटाबेस के साथ बातचीत करने वाले कोड के संचालन के लिए, सिस्टम टेबल में उपयोगकर्ता "user1" के अधिकारों को इंगित किया जाना चाहिए। यदि आप Celesta एक्सेस डिस्ट्रीब्यूशन सिस्टम का उपयोग नहीं करना चाहते हैं और सत्र संदर्भ को किसी भी टेबल पर सभी अधिकार देते हैं, तो आप एक SystemCallContext ऑब्जेक्ट बना सकते हैं।

सेवा स्तर पर चालान को सहेजने की विधि इस तरह दिख सकती है:

 @Service public class DocumentService { @CelestaTransaction public void postOrder(CallContext context, OrderDto doc) { try (OrderHeaderCursor header = new OrderHeaderCursor(context); OrderLineCursor line = new OrderLineCursor(context)) { header.setId(doc.getId()); header.setDate(Date.from(doc.getDate().atStartOfDay(ZoneId.systemDefault()).toInstant())); header.setCustomer_id(doc.getCustomerId()); header.setCustomer_name(doc.getCustomerName()); header.insert(); int lineNo = 0; for (OrderLineDto docLine : doc.getLines()) { lineNo++; line.setLine_no(lineNo); line.setOrder_id(doc.getId()); line.setItem_id(docLine.getItemId()); line.setQty(docLine.getQty()); line.insert(); } } } 

@CelestaTransaction एनोटेशन पर ध्यान दें। इसके लिए धन्यवाद, प्रॉक्सी ऑब्जेक्ट DocumentService सर्विस उन सभी सेवा कार्यों को ऊपर वर्णित CallContext ctx पैरामीटर के साथ करेगा। यही है, विधि निष्पादन की शुरुआत में, यह पहले से ही डेटाबेस कनेक्शन के लिए बाध्य होगा, और लेनदेन शुरू करने के लिए तैयार होगा। हम व्यावसायिक तर्क लिखने पर ध्यान केंद्रित कर सकते हैं। हमारे मामले में, OrderDto ऑब्जेक्ट को पढ़ना और इसे डेटाबेस में सहेजना है।

ऐसा करने के लिए, हम तथाकथित celesta-maven-plugin का उपयोग करते हैं - celesta-maven-plugin का उपयोग करके उत्पन्न कक्षाएं। हम पहले ही देख चुके हैं कि वे क्या हैं। स्कीमा वस्तुओं में से प्रत्येक के लिए एक वर्ग बनाया जाता है - दो टेबल और एक दृश्य। और अब हम अपने व्यावसायिक तर्क में डेटाबेस ऑब्जेक्ट्स तक पहुंचने के लिए इन कक्षाओं का उपयोग कर सकते हैं।

ऑर्डर टेबल पर एक कर्सर बनाने और पहला रिकॉर्ड चुनने के लिए, आपको निम्नलिखित कोड लिखना होगा:

 OrderHeaderCursor header = new OrderHeaderCursor(context); header.tryFirst(); 

हेडर ऑब्जेक्ट बनाने के बाद, हम गेट एंट्री के क्षेत्र को गेटर्स और सेटर के माध्यम से एक्सेस कर सकते हैं:

कर्सर बनाते समय, हमें सक्रिय कॉल संदर्भ का उपयोग करना चाहिए - यह कर्सर बनाने का एकमात्र तरीका है। कॉल संदर्भ वर्तमान उपयोगकर्ता और उसके उपयोग अधिकारों के बारे में जानकारी प्रदान करता है।

कर्सर ऑब्जेक्ट के साथ, हम अलग-अलग चीजें कर सकते हैं: फ़िल्टर, रिकॉर्ड के माध्यम से जाना, और भी, स्वाभाविक रूप से, रिकॉर्ड डालें, हटाएं और अपडेट करें। पूरे कर्सर एपीआई को प्रलेखन में विस्तार से वर्णित किया गया है ।

उदाहरण के लिए, हमारे उदाहरण के कोड को निम्नानुसार विकसित किया जा सकता है:

 OrderHeaderCursor header = new OrderHeaderCursor(context); header.setRange("manager_id", "manager1"); header.tryFirst(); header.setCounter(header.getCounter() + 1); header.update(); 

इस उदाहरण में, हम manager_id फ़ील्ड द्वारा फ़िल्टर सेट करते हैं, फिर हम TryFirst विधि का उपयोग करके पहला रिकॉर्ड पाते हैं।

जब tryFirst ट्रिगर किया tryFirst है, तो tryFirst चर एक रिकॉर्ड के डेटा से भरे होते हैं, हम उन्हें मान पढ़ सकते हैं और असाइन कर सकते हैं। और जब कर्सर में डेटा पूरी तरह से तैयार हो जाता है, तो हम update() निष्पादित करते हैं, और यह डेटाबेस में कर्सर की सामग्री को संग्रहीत करता है।

यह कोड किस समस्या से प्रभावित हो सकता है? बेशक, दौड़ हालत / खो अद्यतन के उद्भव! क्योंकि उस क्षण के बीच जब हमने "tryFirst" के साथ लाइन में डेटा प्राप्त किया था और उस पल जब हम "अपडेट" बिंदु पर इस डेटा को अपडेट करने का प्रयास करते हैं, तो कोई अन्य व्यक्ति डेटाबेस में इस डेटा को पहले ही प्राप्त, संशोधित और अपडेट कर सकता है। डेटा पढ़ने के बाद, कर्सर किसी भी तरह से अन्य उपयोगकर्ताओं द्वारा उनके उपयोग को अवरुद्ध नहीं करता है! खोए हुए अपडेट से बचाने के लिए, सेलेस्टा आशावादी लॉक सिद्धांत का उपयोग करता है। प्रत्येक तालिका में, डिफ़ॉल्ट रूप से, Celesta एक recversion फ़ील्ड बनाता है, और UPDATE ट्रिगर के स्तर पर यह संस्करण संख्या बढ़ाता है और जाँचता है कि अद्यतन किए गए डेटा में तालिका के समान संस्करण है। यदि कोई समस्या होती है, तो एक अपवाद फेंकता है। आप इस लेख के बारे में अधिक पढ़ सकते हैं " सुरक्षा खो अद्यतन के खिलाफ "।

फिर से याद करें कि कॉलकॉन्टेक्स ऑब्जेक्ट के साथ एक लेनदेन जुड़ा हुआ है। यदि सेलेस्टा प्रक्रिया सफल होती है, तो एक प्रतिबद्धता होती है। यदि सेलेस्टा विधि एक अखंड अपवाद के साथ समाप्त होती है, तो रोलबैक होता है। इस प्रकार, यदि कुछ जटिल प्रक्रिया में कोई त्रुटि होती है, तो कॉल संदर्भ से संबंधित संपूर्ण लेन-देन वापस आ जाता है, जैसे कि हमने डेटा के साथ कुछ भी करना शुरू नहीं किया था, डेटा दूषित नहीं है। यदि किसी कारण से आपको किसी प्रकार की बड़ी प्रक्रिया के बीच में एक कमेटी की आवश्यकता होती है, तो वह एक स्पष्ट प्रतिबद्ध है, जिसे context.commit() कहकर निष्पादित किया जा सकता है।

डेटा विधियों का परीक्षण

आइए एक यूनिट टेस्ट बनाएं जो डेटाबेस में OrderDto को स्टोर करने वाली सेवा पद्धति की शुद्धता की जांच करता है।

JUnit5 का उपयोग करते समय और celesta- celesta-unit मॉड्यूल में उपलब्ध JUnit5 के विस्तार के लिए, यह बहुत आसान है। परीक्षण की संरचना इस प्रकार है:

 @CelestaTest public class DocumentServiceTest { DocumentService srv = new DocumentService(); @Test void documentIsPutToDb(CallContext context) { OrderDto doc =... srv.postOrder(context, doc); //Check the fact that records are in the database OrderHeaderCursor header = new OrderHeaderCursor(context); header.tryFirst(); assertEquals(doc.getId(), header.getId()); OrderLineCursor line = new OrderLineCursor(context); line.setRange("order_id", doc.getId()); assertEquals(2, line.count()); } } 

एनोटेशन @CelestaTest के लिए धन्यवाद, जो JUnit5 के लिए एक विस्तार है, हम परीक्षण विधियों में CallContext context पैरामीटर घोषित करने में सक्षम हैं। यह संदर्भ पहले से ही सक्रिय है और डेटाबेस (इन-मेमोरी एच 2) से जुड़ा हुआ है, और इसलिए हमें एक प्रॉक्सी में सेवा वर्ग को लपेटने की आवश्यकता नहीं है - हम इसे new का उपयोग करते हुए बनाते हैं, और वसंत का उपयोग नहीं करते हैं। हालांकि, यदि आवश्यक हो, तो स्प्रिंग टूल का उपयोग करके सेवा को परीक्षण में इंजेक्ट करें, इसके लिए कोई बाधा नहीं है।

हम इस धारणा के तहत इकाई परीक्षण बनाते हैं कि उनके निष्पादन के समय तक डेटाबेस पूरी तरह से खाली हो जाएगा, लेकिन उस संरचना के साथ जिसकी हमें ज़रूरत है, और उनके निष्पादन के बाद हम इस तथ्य के बारे में चिंता नहीं कर सकते कि हमने डेटाबेस में "कचरा" छोड़ दिया है। ये परीक्षण बहुत तेज गति से किए जाते हैं।

आइए एक दूसरी प्रक्रिया बनाएं जो JSON को कुल मूल्यों के साथ लौटाती है जिसमें दिखाया गया है कि हमने कितने उत्पादों का ऑर्डर दिया है।

परीक्षण डेटाबेस को दो आदेश लिखता है, जिसके बाद वह नए getAggregateReport विधि द्वारा लौटाए गए कुल मूल्य की जांच करता है:

 @Test void reportReturnsAggregatedQuantities(CallContext context) { srv.postOrder(context, . . .); srv.postOrder(context, . . .); Map<String, Integer> result = srv.getAggregateReport(context); assertEquals(5, result.get("A").intValue()); assertEquals(7, result.get("B").intValue()); } 

getAggregateReport मेथड को लागू करने के लिए getAggregateReport हम ऑर्डरडेक्टी व्यू का उपयोग करेंगे, जो, मुझे याद है, CelestaSQL फाइल में इस तरह दिखता है:

 create view OrderedQty as select item_id, sum(qty) as qty from OrderLine group by item_id; 

अनुरोध मानक है: हम उत्पाद कोड द्वारा मात्रा और समूह द्वारा आदेश लाइनों को सारांशित करते हैं। व्यू के लिए पहले से ही एक आर्डरक्यूटीकोर्स कर्सर बनाया गया है, जिसका हम उपयोग कर सकते हैं। हम इस कर्सर को घोषित करते हैं, उस पर पुनरावृति करते हैं और वांछित Map<String, Integer> एकत्र करते हैं Map<String, Integer> :

 @CelestaTransaction public Map<String, Integer> getAggregateReport(CallContext context) { Map<String, Integer> result = new HashMap<>(); try (OrderedQtyCursor ordered_qty = new OrderedQtyCursor(context)) { for (OrderedQtyCursor line : ordered_qty) { result.put(ordered_qty.getItem_id(), ordered_qty.getQty()); } } return result; } 

भौतिकतावादी Celesta दृश्य

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

सेलेस्टा उन सभी मानक कार्यों को लागू करने की कोशिश करता है जो व्यापार तर्क प्रोग्रामर लगातार मंच स्तर पर सामना करते हैं।

MS SQL सर्वर में भौतिकीकृत (अनुक्रमित) विचारों की अवधारणा है, जो तालिकाओं के रूप में संग्रहीत हैं और स्रोत तालिकाओं में डेटा के रूप में जल्दी से अपडेट किए जाते हैं। यदि हम "क्लीन" एमएस SQL ​​सर्वर में काम कर रहे थे, तो हमारे मामले के लिए एक अनुक्रमित दृश्य के साथ दृश्य का प्रतिस्थापन सिर्फ वही होगा जिसकी हमें आवश्यकता थी: एकत्रित रिपोर्ट को पुनः प्राप्त करना डेटा के जमा होने के रूप में धीमा नहीं होगा, और एकत्रित रिपोर्ट को अपडेट करने का काम फिलहाल किया जाएगा। आदेश पंक्तियों की तालिका में डेटा सम्मिलित करना और पंक्तियों की संख्या में वृद्धि के साथ बहुत अधिक नहीं बढ़ेगा।

लेकिन अगर हम Celesta के माध्यम से PostgreSQL के साथ काम करते हैं, तो हम क्या कर सकते हैं? भौतिक शब्द को जोड़कर दृश्य को फिर से परिभाषित करें:

 create materialized view OrderedQty as select item_id, sum(qty) as qty from OrderLine group by item_id; 

आइए सिस्टम शुरू करें और देखें कि डेटाबेस का क्या हुआ।

हम देखेंगे कि OrderedQty गायब हो गया है, और OrderedQty तालिका दिखाई दी है। उसी समय, जैसा कि ऑर्डरलाइन तालिका डेटा से भरी हुई है, ऑर्डरडेक्टी तालिका में जानकारी "जादुई रूप से" अपडेट की जाएगी, जैसे कि ऑर्डरडीकटी एक दृश्य होगा।

यहां कोई जादू नहीं है अगर हम OrderLine टेबल पर बने ट्रिगर्स को देखते हैं। सेलेस्टा ने "भौतिक दृष्टि" बनाने का कार्य प्राप्त किया, क्वेरी का विश्लेषण किया और OrderedQty तालिका पर OrderedQty बनाया जो कि OrderedQty अपडेट OrderedQty । CelestaSQL-file में एक भी कीवर्ड - भौतिकीकृत - सम्मिलित करके, हमने प्रदर्शन में गिरावट की समस्या को हल किया, और व्यापार तर्क कोड को भी बदलने की आवश्यकता नहीं थी!

, , , . «» Celesta , , JOIN-, GROUP BY. , , , , . . .

निष्कर्ष

Celesta. — .