Liquibase प्रयोग गरेर खुट्टामा आफैलाई गोली हान्नबाट कसरी बच्ने

पहिले कहिल्यै भएको थिएन, र यहाँ हामी फेरि जान्छौं!

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

लेखमा उपयोगी सुझावहरू र तीनवटा सबैभन्दा स्पष्ट समस्याहरूको विवरण समावेश छ जुन तपाईं रिलेसनल डाटाबेस माइग्रेसन उपकरणहरूसँग काम गर्दा, विशेष Liquibase मा पर्न सक्नुहुन्छ। जुनियर र मध्य स्तरहरूमा Java विकासकर्ताहरूका लागि डिजाइन गरिएको; अधिक अनुभवी विकासकर्ताहरूको लागि यो संरचना र दोहोर्याउनको लागि चासोको हुन सक्छ जुन सम्भवतः पहिले नै थाहा छ।

Liquibase र Flyway जाभा संसारमा रिलेशनल संरचनाहरूको संस्करण नियन्त्रण समस्याहरू समाधान गर्नका लागि मुख्य प्रतिस्पर्धी प्रविधिहरू हुन्। पहिलो पूर्ण रूपमा नि: शुल्क छ, व्यवहारमा यो प्रायः प्रयोगको लागि छनौट गरिन्छ, त्यसैले Liquibase प्रकाशनको नायकको रूपमा रोजिएको थियो। यद्यपि, तपाइँको एप्लिकेसन आर्किटेक्चरमा निर्भर गर्दै, वर्णन गरिएका केही अभ्यासहरू विश्वव्यापी हुन सक्छन्।

रिलेशनल ढाँचाहरूको माइग्रेसनहरू रिलेशनल डाटा स्टोरहरूको कमजोर लचिलोपनसँग सम्झौता गर्न बाध्य तरिका हो। OOP फेसनको युगमा, डाटाबेसहरूसँग काम गर्ने शैलीको अर्थ हामीले स्किमालाई एक पटक वर्णन गर्ने र यसलाई फेरि छुने छैन। तर वास्तविकता सधैं यो हो कि चीजहरू परिवर्तन हुन्छन्, र तालिका संरचनामा परिवर्तनहरू प्रायः आवश्यक हुन्छन्। स्वाभाविक रूपमा, प्रक्रिया आफै पीडादायी र अप्रिय हुन सक्छ।

म तपाइँको परियोजनामा ​​पुस्तकालय थप्नको लागि टेक्नोलोजी र निर्देशनहरूको विवरणमा गहिरो जानेछैन; यस विषयमा धेरै लेखहरू लेखिएका छन्:

• वसन्त बुट अनुप्रयोगमा डेटाबेस संरचना व्यवस्थापन गर्न Liquibase प्रयोग गर्दै। भाग 1
• वसन्त बुट अनुप्रयोगमा डेटाबेस संरचना व्यवस्थापन गर्न Liquibase प्रयोग गर्दै। भाग 2
• Liquibase र Maven
• डाटाबेस परिवर्तन संस्करणको लागि दृष्टिकोण
• हामीले Spring MVC/Security, REST, Hibernate, Liquibase लाई दुई लाइनमा सुरु गर्छौं

यसको अतिरिक्त, उपयोगी सुझावहरूको विषयमा पहिले नै उत्कृष्ट लेख थियो:

• टाउको दुखाइ बिना Liquibase प्रयोग गर्दै। वास्तविक विकास अनुभवबाट 10 सुझावहरू

Советы

बसाइँसराइको समस्या समाधानका लागि पसिना, रगत र पीडाले जन्मिएका मेरा सुझाव र टिप्पणीहरू बाँड्न चाहन्छु ।

1. काम सुरु गर्नु अघि, तपाईंले आफूलाई सबैभन्दा राम्रो अभ्यास खण्डमा परिचित गर्नुपर्छ साइट Liquibase

त्यहाँ सरल तर धेरै महत्त्वपूर्ण कुराहरू वर्णन गरिएको छ, जसको बिना पुस्तकालयको प्रयोगले तपाईंको जीवनलाई जटिल बनाउन सक्छ। उदाहरणका लागि, परिवर्तनहरू प्रबन्ध गर्नको लागि एक असंरचित दृष्टिकोणले ढिलो वा पछि भ्रम र भाँचिएको माइग्रेसन निम्त्याउँछ। यदि तपाइँ एकै समयमा डाटाबेस संरचना र सेवा तर्कमा पारस्परिक रूपमा निर्भर परिवर्तनहरू रोल आउट गर्नुहुन्न भने, त्यहाँ एक उच्च सम्भावना छ कि यसले रातो परीक्षण वा बिग्रिएको वातावरण निम्त्याउनेछ। थप रूपमा, आधिकारिक वेबसाइटमा Liquibase प्रयोग गर्नका लागि सिफारिसहरूमा मुख्य माइग्रेसन लिपिहरूसँगै रोलब्याक स्क्रिप्टहरूको विकास र परीक्षणको बारेमा एउटा क्लज समावेश छ। खैर, लेखमा https://habr.com/ru/post/178665/ माइग्रेसन र रोलब्याक मेकानिजमको सन्दर्भमा कोड उदाहरणहरू छन्।

2. यदि तपाईंले माइग्रेसन उपकरणहरू प्रयोग गर्न थाल्नुभयो भने, डाटाबेस संरचनामा म्यानुअल सुधारहरूलाई अनुमति नदिनुहोस्

भनाइ अनुसार: "एक पटक पर्सिल, सधैं Persil।" यदि तपाईंको आवेदनको आधार Liquibase द्वारा व्यवस्थित हुन थाल्छ भने, कुनै पनि म्यानुअल परिवर्तनहरूले तुरुन्तै असंगत स्थितिमा लैजान्छ, र परिवर्तनहरूमा विश्वासको स्तर शून्य हुन्छ। सम्भावित जोखिमहरूमा डाटाबेस पुनर्स्थापना गर्न बिताएको धेरै घण्टाहरू समावेश छन्; सबैभन्दा खराब अवस्थामा, एक मृत सर्भर। यदि तपाइँसँग तपाइँको टोलीमा "पुरानो विद्यालय" DBA आर्किटेक्ट छ भने, धैर्यतापूर्वक र विचारपूर्वक उसलाई बुझाउनुहोस् कि यदि उसले केवल सशर्त SQL विकासकर्ताबाट आफ्नै बुझाइ अनुसार डाटाबेस सम्पादन गर्दछ भने कति खराब हुनेछ।

3. यदि परिवर्तनसेट पहिले नै भण्डारमा धकेलिएको छ भने, सम्पादनबाट बच्नुहोला

यदि अर्को विकासकर्ताले पुल बनायो र परिवर्तनसेट लागू गर्यो, जुन पछि सम्पादन गरिनेछ, उसले निश्चित रूपमा तपाइँलाई दयालु शब्दको साथ सम्झनेछ जब उसले अनुप्रयोग सुरु गर्दा त्रुटि प्राप्त गर्दछ। यदि परिवर्तनसेट सम्पादन गर्दा कुनै न कुनै रूपमा विकासमा चुहावट भयो भने, तपाईंले हटफिक्सहरूको चिप्लो ढलानलाई पछ्याउनु पर्छ। समस्याको सार ह्यास योग - Liquibase को मुख्य संयन्त्र द्वारा परिवर्तनहरूको प्रमाणीकरण मा निर्भर गर्दछ। चेन्जसेट कोड सम्पादन गर्दा, ह्यास रकम परिवर्तन हुन्छ। परिवर्तनहरू सम्पादन गर्न सम्भव छ तब मात्र सम्भव छ जब सम्पूर्ण डाटाबेसलाई स्क्र्याचबाट डाटा नगुमाउन सम्भव हुन्छ। यस अवस्थामा, SQL वा XML कोड रिफ्याक्टरिंगले, यसको विपरित, जीवनलाई सजिलो बनाउन र माइग्रेसनहरूलाई थप पढ्न योग्य बनाउन सक्छ। एउटा उदाहरण एउटा स्थिति हुनेछ जहाँ, अनुप्रयोगको सुरुमा, स्रोत डाटाबेसको स्कीमा टोली भित्र सहमत भएको थियो।

4. सम्भव भएमा डाटाबेस ब्याकअपहरू प्रमाणित गर्नुहोस्

यहाँ, मलाई लाग्छ, सबै कुरा स्पष्ट छ। यदि अचानक माइग्रेसन असफल भयो भने, सबै कुरा फिर्ता गर्न सकिन्छ। Liquibase सँग परिवर्तनहरू रोल ब्याक गर्नको लागि एउटा उपकरण छ, तर रोलब्याक स्क्रिप्टहरू पनि विकासकर्ता आफैले लेखेका छन्, र तिनीहरूसँग मुख्य परिवर्तनसेटको स्क्रिप्टहरू जस्तै सम्भाव्यतासँग समस्या हुन सक्छ। यसको मतलब यो कुनै पनि अवस्थामा ब्याकअप संग सुरक्षित प्ले गर्न उपयोगी छ।

5. सम्भव भएमा, विकासमा प्रमाणित डाटाबेस ब्याकअपहरू प्रयोग गर्नुहोस्

यदि यसले सम्झौता र गोपनीयताको विरोध गर्दैन भने, डेटाबेसमा कुनै व्यक्तिगत डेटा छैन, र यसले दुई सूर्य जत्तिकै तौल गर्दैन - यसलाई प्रत्यक्ष माइग्रेसन सर्भरहरूमा प्रयोग गर्नु अघि, तपाइँ विकासकर्ताको मेसिनमा कसरी काम गर्दछ भनेर जाँच गर्न सक्नुहुन्छ र गणना गर्न सक्नुहुन्छ। माइग्रेसनको समयमा सम्भावित समस्याहरूको लगभग 100%।

6. टोलीमा अन्य विकासकर्ताहरूसँग कुराकानी गर्नुहोस्

राम्रो संगठित विकास प्रक्रियामा, टोलीमा सबैलाई थाहा छ कसले के गरिरहेको छ। वास्तवमा, यो प्राय: मामला होइन, त्यसैले, यदि तपाइँ तपाइँको कार्य को एक भाग को रूप मा डाटाबेस संरचना मा परिवर्तन को तैयारी गर्दै हुनुहुन्छ, यो अतिरिक्त सम्पूर्ण टीम को बारे मा सूचित गर्न को लागी सलाह छ। यदि कसैले समानान्तर परिवर्तन गर्दैछ भने, तपाईंले सावधानीपूर्वक व्यवस्थित गर्नुपर्छ। यो काम सकिएपछि सहकर्मीहरूसँग कुराकानी गर्न लायक छ, सुरुमा मात्र होइन। परिवर्तनहरू संग धेरै सम्भावित समस्याहरू कोड समीक्षा चरणमा समाधान गर्न सकिन्छ।

7. तपाई के गर्दै हुनुहुन्छ भनेर सोच्नुहोस्!

यो कुनै पनि परिस्थितिमा लागू हुने आत्म-स्पष्ट सल्लाह जस्तो देखिन्छ। यद्यपि, विकासकर्ताले आफूले के गरिरहनुभएको छ र यसले के असर गर्न सक्छ भनेर फेरि विश्लेषण गरेको भए धेरै समस्याहरू टार्न सकिन्थ्यो। माइग्रेसनहरूसँग काम गर्न सधैं थप ध्यान र शुद्धता चाहिन्छ।

जाल

अब माथिको सल्लाह पालना नगरेमा तपाईं फस्न सक्ने सामान्य जालहरू हेरौं, र तपाईंले वास्तवमा के गर्नुपर्छ?

स्थिति 1: दुई विकासकर्ताहरू एकै समयमा नयाँ परिवर्तनहरू थप्न प्रयास गर्दै छन्

Vasya र Petya एक-अर्काको बारेमा थाहा नपाई परिवर्तनसेट संस्करण 4 सिर्जना गर्न चाहन्छन्। तिनीहरूले डाटाबेस संरचनामा परिवर्तनहरू गरे र विभिन्न परिवर्तनसेट फाइलहरूसँग पुल अनुरोध जारी गरे। निम्न कार्य संयन्त्र प्रस्तावित छ:

कसरी निर्णय गर्ने

1. कुनै न कुनै रूपमा, सहकर्मीहरूले तिनीहरूको परिवर्तनहरू जाने क्रममा सहमत हुनुपर्छ, उदाहरणका लागि, पेटिन पहिले लागू गर्नुपर्छ।
2. कसैले आफैंमा दोस्रो थप्नु पर्छ र संस्करण 5 सँग Vasya को परिवर्तनहरू चिन्ह लगाउनु पर्छ। यो चेरी पिक वा सफा मर्ज मार्फत गर्न सकिन्छ।
3. परिवर्तनहरू पछि, तपाईंले निश्चित रूपमा लिइएका कार्यहरूको वैधता जाँच गर्नुपर्छ।
   वास्तवमा, Liquibase मेकानिजमहरूले तपाईंलाई भण्डारमा दुई संस्करण 4 परिवर्तनहरू राख्न अनुमति दिनेछ, त्यसैले तपाईंले सबै कुरा यथास्थिति छोड्न सक्नुहुन्छ। त्यो हो, तपाइँसँग संस्करण 4 मा फरक नामहरूको साथ दुईवटा परिवर्तनहरू हुनेछन्। यस दृष्टिकोणको साथ, डाटाबेस संस्करणहरू नेभिगेट गर्न पछि यो धेरै गाह्रो हुन्छ।

यसको अतिरिक्त, Liquibase, hobbits को घर जस्तै, धेरै गोप्य राख्छ। ती मध्ये एउटा हो validCheckSum कुञ्जी, जुन संस्करण १.७ मा देखा पर्‍यो र तपाइँलाई डाटाबेसमा के भण्डारण गरिएको भएतापनि, कुनै खास परिवर्तनको लागि वैध ह्यास मान निर्दिष्ट गर्न अनुमति दिन्छ। दस्तावेजीकरण https://www.liquibase.org/documentation/changeset.html निम्न भन्छन्:

डाटाबेसमा के भण्डारण गरिएको भएतापनि यो परिवर्तन सेटको लागि मान्य मानिने चेकसम थप्नुहोस्। मुख्य रूपमा प्रयोग गरिन्छ जब तपाइँ परिवर्तन सेट परिवर्तन गर्न आवश्यक पर्दछ र डाटाबेसमा फ्याँकिएको त्रुटिहरू चाहनुहुन्न जसमा यो पहिले नै चलेको छ (सिफारिस गरिएको प्रक्रिया होइन)

हो, हो, यो प्रक्रिया सिफारिस गरिएको छैन। तर कहिलेकाहीँ एक बलियो प्रकाश जादूगरले अँध्यारो प्रविधिहरू पनि मास्टर गर्दछ

स्थिति २: माइग्रेसन जुन डाटामा निर्भर हुन्छ

मानौं तपाईंसँग लाइभ सर्भरबाट डाटाबेस ब्याकअपहरू प्रयोग गर्ने क्षमता छैन। Petya ले एक परिवर्तनसेट सिर्जना गर्यो, यसलाई स्थानीय रूपमा परीक्षण गर्यो र, उनी सही थिए भन्ने पूर्ण विश्वासका साथ, विकासकर्तालाई पुल अनुरोध गरे। केवल के अवस्थामा, परियोजना नेतृत्वले स्पष्ट गर्यो कि पेटियाले यसलाई जाँच गरेको थियो, र त्यसपछि थपियो। तर विकास सर्भरमा तैनाती घट्यो।

वास्तवमा, यो सम्भव छ, र कोही पनि यसबाट प्रतिरक्षा छैन। यो तब हुन्छ यदि तालिका संरचनामा परिमार्जनहरू कुनै न कुनै रूपमा डाटाबेसबाट विशिष्ट डेटासँग जोडिएको हुन्छ। जाहिर छ, यदि पेटियाको डाटाबेस परीक्षण डाटाले मात्र भरिएको छ, तब यसले सबै समस्याका केसहरूलाई समेट्न सक्दैन। उदाहरणका लागि, तालिका मेटाउँदा, विदेशी कुञ्जीद्वारा अन्य तालिकाहरूमा रेकर्डहरू छन् जुन मेटाइएका रेकर्डहरूसँग सम्बन्धित छन्। वा स्तम्भ प्रकार परिवर्तन गर्दा, यो थाहा हुन्छ कि डाटाको 100% नयाँ प्रकारमा रूपान्तरण गर्न सकिँदैन।

कसरी निर्णय गर्ने

• विशेष स्क्रिप्टहरू लेख्नुहोस् जुन माइग्रेसनसँगै एक पटक प्रयोग गरिनेछ र डाटालाई उपयुक्त फारममा ल्याउनुहोस्। यो माइग्रेसन लागू गरेपछि नयाँ संरचनाहरूमा डाटा स्थानान्तरण गर्ने समस्या समाधान गर्ने एक सामान्य तरिका हो, तर विशेष अवस्थामा पहिले पनि यस्तै कुरा लागू गर्न सकिन्छ। यो मार्ग, निस्सन्देह, सधैं उपलब्ध छैन, किनभने प्रत्यक्ष सर्भरहरूमा डाटा सम्पादन खतरनाक र विनाशकारी पनि हुन सक्छ।
• अर्को कठिन तरिका अवस्थित परिवर्तनसेट सम्पादन गर्नु हो। कठिनाई यो छ कि सबै डाटाबेसहरू जहाँ यो पहिले नै यसको अवस्थित फारममा लागू भइसकेको छ पुनर्स्थापना गर्नुपर्नेछ। यो सम्भव छ कि सम्पूर्ण ब्याकएन्ड टोलीलाई स्थानीय रूपमा स्क्र्याचबाट डाटाबेस रोल आउट गर्न बाध्य गरिनेछ।
• र सबैभन्दा सार्वभौमिक तरिका भनेको विकासकर्ताको वातावरणमा डाटाको साथ समस्यालाई स्थानान्तरण गर्नु हो, उही अवस्थालाई पुन: सिर्जना गर्नु र नयाँ परिवर्तनसेट थप्नु, भाँचिएकोमा, जसले समस्यालाई रोक्नेछ।
  

सामान्यतया, उत्पादन सर्भर डाटाबेसको संरचनामा डाटाबेस जति धेरै समान हुन्छ, माइग्रेसनका समस्याहरू टाढा जाने सम्भावना कम हुन्छ। र, निस्सन्देह, तपाईंले भण्डारमा परिवर्तनहरू पठाउनु अघि, तपाईंले धेरै पटक सोच्नुपर्छ कि यसले केहि तोड्छ कि सक्दैन।

स्थिति 3. Liquibase उत्पादनमा गए पछि प्रयोग गर्न सुरु हुन्छ

मानौं कि टोलीको नेतृत्वले पेटियालाई परियोजनामा ​​लिक्विबेस समावेश गर्न भन्यो, तर परियोजना पहिले नै उत्पादनमा छ र त्यहाँ अवस्थित डाटाबेस संरचना छ।

तदनुसार, समस्या यो हो कि कुनै पनि नयाँ सर्भर वा विकासकर्ता मेसिनहरूमा, यी तालिकाहरू स्क्र्याचबाट पुन: सिर्जना गरिनु पर्छ, र अवस्थित वातावरण एक सुसंगत अवस्थामा रहनुपर्छ, नयाँ परिवर्तनहरू स्वीकार गर्न तयार हुनुपर्छ।

कसरी निर्णय गर्ने

त्यहाँ पनि धेरै तरिकाहरू छन्:

• पहिलो र सबैभन्दा स्पष्ट एउटा छुट्टै लिपि हुनु हो जुन नयाँ वातावरण सुरु गर्दा म्यानुअल रूपमा लागू गर्नुपर्छ।
• दोस्रो कम स्पष्ट छ, एक Liquibase माइग्रेसन छ जुन अर्को Liquibase सन्दर्भमा छ, र यसलाई लागू गर्नुहोस्। तपाईं यहाँ Liquibase सन्दर्भ बारे थप पढ्न सक्नुहुन्छ: https://www.liquibase.org/documentation/contexts.html। सामान्यतया, यो एक रोचक संयन्त्र हो जुन सफलतापूर्वक प्रयोग गर्न सकिन्छ, उदाहरणका लागि, परीक्षणको लागि।
• तेस्रो मार्गमा धेरै चरणहरू छन्। पहिले, अवस्थित तालिकाहरूको लागि माइग्रेसन सिर्जना गर्नुपर्छ। त्यसपछि यो केहि वातावरणमा लागू गरिनु पर्छ र यसरी यसको ह्यास योग प्राप्त हुनेछ। अर्को चरण हाम्रो गैर-खाली सर्भरमा खाली Liquibase तालिकाहरू प्रारम्भ गर्नु हो, र परिवर्तनसेटहरूको प्रयोगको इतिहासको साथ तालिकामा, तपाईंले म्यानुअल रूपमा डाटाबेसमा अवस्थित परिवर्तनहरूसँग "जस्तै लागू गरिएको" परिवर्तनहरूको बारेमा रेकर्ड राख्न सक्नुहुन्छ। । यसरी, अवस्थित सर्भरमा, इतिहास काउन्टडाउन संस्करण २ बाट सुरु हुनेछ, र सबै नयाँ वातावरणहरूले समान रूपमा व्यवहार गर्नेछन्।
  

स्थिति 4. बसाइसराईहरू ठूलो हुन्छन् र पूरा गर्न समय हुँदैन

सेवा विकासको सुरुमा, एक नियमको रूपमा, Liquibase बाह्य निर्भरताको रूपमा प्रयोग गरिन्छ, र सबै माइग्रेसनहरू प्रशोधन गरिन्छ जब अनुप्रयोग सुरु हुन्छ। जे होस्, समयको साथमा, तपाइँ निम्न केसहरूमा ठोकर लाग्न सक्नुहुन्छ:

• माइग्रेसनहरू ठूलो हुन्छन् र पूरा हुन लामो समय लाग्छ।
• त्यहाँ वितरित वातावरणमा माइग्रेसनको आवश्यकता छ, उदाहरणका लागि, एकै साथ धेरै डाटाबेस सर्भर उदाहरणहरूमा।
  यस अवस्थामा, धेरै लामो समयसम्म माइग्रेसनहरू लागू गर्दा अनुप्रयोग सुरु हुँदा समय समाप्त हुनेछ। थप रूपमा, प्रत्येक अनुप्रयोग उदाहरणमा अलग-अलग माइग्रेसनहरू लागू गर्दा विभिन्न सर्भरहरू सिंक बाहिर हुन सक्छ।

कसरी निर्णय गर्ने

यस्तो अवस्थामा, तपाईंको परियोजना पहिले नै ठूलो छ, सायद एक वयस्क पनि, र Liquibase एक अलग बाह्य उपकरणको रूपमा कार्य गर्न थाल्छ। तथ्य यो हो कि Liquibase लाई लाइब्रेरीको रूपमा जार फाइलमा कम्पाइल गरिएको छ, र परियोजना भित्र वा स्वतन्त्र रूपमा निर्भरताको रूपमा काम गर्न सक्छ।

स्ट्यान्डअलोन मोडमा, तपाईं आफ्नो CI/CD वातावरणमा वा तपाईंको प्रणाली प्रशासकहरू र तैनाती विशेषज्ञहरूको बलियो काँधहरूमा माइग्रेसनको कार्यान्वयन छोड्न सक्नुहुन्छ। यो गर्नको लागि तपाईंलाई Liquibase कमाण्ड लाइन चाहिन्छ https://www.liquibase.org/documentation/command_line.html। यस मोडमा, सबै आवश्यक माइग्रेसनहरू गरिसकेपछि अनुप्रयोग सुरू गर्न सम्भव हुन्छ।

निष्कर्षमा

वास्तवमा, डाटाबेस माइग्रेसनको साथ काम गर्दा त्यहाँ धेरै थप समस्याहरू हुन सक्छन्, र तिनीहरूमध्ये धेरैलाई रचनात्मक दृष्टिकोण चाहिन्छ। यो बुझ्न महत्त्वपूर्ण छ कि यदि तपाइँ उपकरणलाई सही रूपमा प्रयोग गर्नुहुन्छ भने, यी प्रायः समस्याहरूबाट बच्न सकिन्छ। विशेष रूपमा, मैले विभिन्न रूपहरूमा सूचीबद्ध गरिएका सबै समस्याहरूको सामना गर्नुपर्‍यो, र तीमध्ये केही मेरा गल्तीहरूको परिणाम थिए। प्रायः यो हुन्छ, अवश्य पनि, बेवास्ताको कारण, तर कहिलेकाहीँ उपकरण प्रयोग गर्न आपराधिक असक्षमताको कारण।

स्रोत: www.habr.com