फ्लाईवे: डेटाबेस माइग्रेशन मैनेजमेंट

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


प्रदर्शन प्रदाता नियमित रूप से डेटाबेस ऑब्जेक्ट के रूप में वर्तमान ऑब्जेक्ट मॉडल को निर्यात करने के लिए केवल एक रूप या किसी अन्य में अनुमति देते हैं। इस प्रक्रिया को फिर से निर्माण (संपूर्ण संरचना को पूरी तरह से हटाने के साथ), अद्यतन (परिवर्तन के साथ) या सुलह (परिवर्तन किए बिना) के साथ किया जा सकता है। उदाहरण के लिए, हाइबरनेट में, यह hbm2ddl टूल का उपयोग करके किया जाता है, जिसके संचालन को हाइबरनेट ।fg.xml या persistence.xml फ़ाइल में एकल कॉन्फ़िगरेशन पैरामीटर के साथ कॉन्फ़िगर किया जा सकता है। हालांकि, फिर से निर्माण (मोड बनाएँ) अवांछनीय है यदि डेटाबेस में पहले से ही डेटा है, और अपडेट (अपडेट मोड) में सभी परिवर्तन नहीं होते हैं, लेकिन केवल गैर-विनाशकारी वाले (उदाहरण के लिए, कॉलम और टेबल हटाए नहीं जाते हैं) और आवश्यक डेटा पुनर्गठन के लिए नहीं लेते हैं। अक्सर, यदि डेटा मॉडल में कई बदलाव हुए हैं, तो उन्हें परिचालन आधार पर लागू करना मुश्किल हो सकता है, खासकर अगर डेटाबेस का वर्तमान संस्करण अज्ञात है। एक तरीका या दूसरा, लेकिन आपको एसक्यूएल स्क्रिप्ट्स को "स्टूप" करना होगा - यह वह जगह है जहां संस्करण नियंत्रण का सवाल आता है।

flyway

परियोजना का मुख्य पृष्ठ समान समाधानों के साथ पुस्तकालय की तुलना में एक स्पष्ट तालिका प्रदान करता है, और यहां मैं समृद्ध कार्यक्षमता पर ध्यान केंद्रित करना चाहता हूं, सरल एसक्यूएल फ़ाइलों या जावा कक्षाओं के रूप में माइग्रेशन के साथ काम करना (उत्तरार्द्ध अनिवार्य रूप से स्प्रिंग जेडीबीसी टेम्पलेट पर आधारित है) और मूल एसक्यूएल समर्थन लोकप्रिय DBMSs (Oracle PL / SQL, SQL Server T / SQL, MySQL और PostgreSQL संग्रहीत कार्यविधियाँ)।

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

फ्लाईवे को प्रोजेक्ट से कनेक्ट करें

सबसे पहले, प्रोजेक्ट के src / main / resource उपनिर्देशिका में db / माइग्रेशन फ़ोल्डर बनाएँ: माइग्रेशन स्क्रिप्ट्स को इसमें संग्रहीत किया जाएगा। चलो वहाँ एक पूर्व निर्यात डेटाबेस स्क्रिप्ट - सभी तालिकाओं, विचारों, अनुक्रमित, आदि के साथ। फ़ाइल का नाम V1__Base_version.sql। माइग्रेशन के लिए नामकरण सम्मेलनों को विस्तार से प्रलेखन में वर्णित किया गया है , अब यह कहने के लिए पर्याप्त है कि फ़ाइल का नाम V से शुरू होता है, इसके बाद संस्करण संख्या (विभाजक बिंदुओं की एक मनमानी संख्या के साथ), एक डबल अंडरस्कोर और माइग्रेशन का वर्णन है।

प्रोजेक्ट निर्भरता (निर्भरता अनुभाग) में फ्लाईवे लाइब्रेरी का मूल जोड़ें:

<dependency> <groupId>com.googlecode.flyway</groupId> <artifactId>flyway-core</artifactId> <version>1.5</version> </dependency> 

और असेंबली प्लगइन्स (अनुभाग बिल्ड / प्लगइन्स) - फ्लाईवे प्लगइन:

 <plugin> <groupId>com.googlecode.flyway</groupId> <artifactId>flyway-maven-plugin</artifactId> <version>1.5</version> <configuration> <driver>com.mysql.jdbc.Driver</driver> <url>jdbc:mysql://localhost:3306/flywaytest?autoReconnect=true&amp;useUnicode=true&amp;characterEncoding=UTF-8&amp;connectionCollation=utf8_general_ci&amp;characterSetResults=UTF-8</url> <baseDir>db/migration</baseDir> </configuration> </plugin> 

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

 <configuration> <user>flyway</user> <password>mySecretPassword</password> ... </configuration> 

या कमांड लाइन विकल्प में:

 -Dflyway.user=flyway -Dflyway.password=mySecretPwd 

लेकिन मावेन पर असेंबली के मामले में, एक अधिक सुविधाजनक तरीका, मावेन सेटिंग्स फ़ाइल (सेटिंग्स.xml फ़ाइल) में मानक पैरामीटर रखना है और सभी समान परियोजनाओं में उनका आगे उपयोग करना है:

 <servers> <server> <id>flyway-db</id> <username>flyway</username> <password>mySecretPassword</password> </server> </servers> 

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

 mvn flyway:clean 

कार्य के सफल समापन पर, डेटाबेस खाली हो जाएगा, और निम्न लाइनें मावेन लॉग में दिखाई देंगी:

 [INFO] --- flyway-maven-plugin:1.5:clean (default-cli) @ flyway-test-project --- [INFO] Cleaned database schema 'flywaytest' (execution time 00:03.911s) 

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

 mvn flyway:init -Dflyway.initialVersion=1 -Dflyway.initialDescription="Base version" 

इसके बाद, आप सत्यापित कर सकते हैं कि स्कीमा_version तालिका डेटाबेस में एकल रिकॉर्ड के साथ दिखाई देती है जो डेटाबेस की वर्तमान स्थिति से मेल खाती है:



हम फ़्लाइवे को एक स्प्रिंग बीन के रूप में अनुप्रयोग के साथ एकीकृत करते हैं जो कि UnitManagerFactory से पहले शुरू होता है:

 <bean id="flyway" class="com.googlecode.flyway.core.Flyway" init-method="migrate"> <property name="dataSource" ref="..."/> ... </bean> <!--        Flyway,  ,          --> <bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="entityManagerFactory" depends-on="flyway"> ... </bean> 

एक स्वच्छ आधार पर आवेदन शुरू करने के बाद, इसे V1__Base_version.sql स्क्रिप्ट के साथ आरंभीकृत किया जाएगा, इसके अलावा, एक स्कीमा_version तालिका बनाई जाएगी। लॉग में, आप निम्नलिखित देख सकते हैं:

 2012-04-04 06:42:09,279 INFO [com.googlecode.flyway.core.metadatatable.MetaDataTable] -- <Metadata table created: schema_version (Schema: flywaytest)> 2012-04-04 06:42:09,318 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Current schema version: null> 2012-04-04 06:42:09,320 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Migrating to version 1> 2012-04-04 06:42:24,897 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Successfully applied 1 migration (execution time 00:15.615s).> 

यदि आवेदन अंतिम प्रवास के समान आधार पर शुरू किया गया था, तो इस योजना में कोई परिवर्तन नहीं होगा, जो निम्नलिखित लाइनों में आवेदन लॉग में परिलक्षित होगा:

 2012-04-04 06:36:14,081 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Current schema version: 1> 2012-04-04 06:36:14,085 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Schema is up to date. No migration necessary.> 

किसी भी स्थिति में, फ्लाईवे के सही एकीकरण के साथ, डेटाबेस में एक प्रविष्टि के साथ उपरोक्त स्कीमा_वर्जन तालिका होनी चाहिए।

प्रवास बनाएँ

V2_Test_change.sql नाम और निम्न सामग्री के साथ db / माइग्रेशन फ़ोल्डर में एक फ़ाइल बनाएँ:

 create table test_table ( id bigint(20) not null, primary key(id) ); 

आवेदन शुरू करने के बाद, हम लॉग में निम्नलिखित पंक्तियाँ पाते हैं:

 2012-04-04 06:51:02,708 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Current schema version: 1> 2012-04-04 06:51:02,710 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Migrating to version 2> 2012-04-04 06:51:03,137 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Successfully applied 1 migration (execution time 00:00.480s).> 

और सुनिश्चित करें कि test_table सफलतापूर्वक बनाया गया था, और स्कीमा_version तालिका में लागू माइग्रेशन के बारे में एक प्रविष्टि दिखाई दी:

रोलबैक माइग्रेशन

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