લિક્વિબેઝનો ઉપયોગ કરીને પોતાને પગમાં કેવી રીતે મારવું નહીં

તે ક્યારેય બન્યું નથી, અને અહીં તે ફરીથી છે!

આગળના પ્રોજેક્ટ પર, અમે ભવિષ્યમાં સમસ્યાઓ ટાળવા માટે શરૂઆતથી જ લિક્વિબેઝનો ઉપયોગ કરવાનું નક્કી કર્યું. જેમ જેમ તે બહાર આવ્યું છે, ટીમના તમામ યુવા સભ્યો તેનો યોગ્ય રીતે ઉપયોગ કેવી રીતે કરવો તે જાણતા નથી. મેં એક આંતરિક વર્કશોપ કર્યું, જે પછી મેં લેખમાં ફેરવવાનું નક્કી કર્યું.

આ લેખમાં ખાસ કરીને રિલેશનલ ડેટાબેઝ માઈગ્રેશન ટૂલ્સ, લિક્વિબેઝ સાથે કામ કરતી વખતે તમને પડી શકે તેવી ત્રણ સૌથી સ્પષ્ટ મુશ્કેલીઓના મદદરૂપ ટીપ્સ અને વર્ણનો શામેલ છે. જુનિયર અને મિડલ લેવલના જાવા ડેવલપર્સ માટે રચાયેલ છે, વધુ અનુભવી ડેવલપર્સ માટે તે સંરચના અને પુનરાવર્તિત કરવા માટે રસપ્રદ હોઈ શકે છે જે સંભવતઃ પહેલેથી જ જાણીતું છે.

લિક્વિબેઝ અને ફ્લાયવે એ જાવા વિશ્વમાં રીલેશનલ સ્ટ્રક્ચર્સના વર્ઝન કંટ્રોલની સમસ્યાઓને ઉકેલવા માટેની મુખ્ય સ્પર્ધાત્મક તકનીકો છે. પ્રથમ સંપૂર્ણપણે મફત છે, વ્યવહારમાં તે વધુ વખત ઉપયોગ માટે પસંદ કરવામાં આવે છે, તેથી જ લિક્વિબેઝને પ્રકાશનના હીરો તરીકે પસંદ કરવામાં આવ્યો હતો. જો કે, તમારી એપ્લિકેશનના આર્કિટેક્ચરના આધારે વર્ણવેલ કેટલીક પ્રથા સામાન્ય હોઈ શકે છે.

રિલેશનલ માઇગ્રેશન એ રિલેશનલ ડેટા સ્ટોર્સની નબળી લવચીકતા સાથે કામ કરવા માટે ફરજિયાત માર્ગ છે. OOP માટે ફેશનના યુગમાં, ડેટાબેઝ સાથે કામ કરવાની શૈલીનો અર્થ એ હતો કે અમે સ્કીમાનું એકવાર વર્ણન કરીશું અને તેને ફરીથી સ્પર્શ કરીશું નહીં. પરંતુ વાસ્તવિકતા એ છે કે વસ્તુઓ બદલાતી રહે છે, અને કોષ્ટકોની રચનામાં ફેરફાર ઘણી વાર જરૂરી હોય છે. સ્વાભાવિક રીતે, પ્રક્રિયા પોતે પીડાદાયક અને અપ્રિય છે.

હું તમારા પ્રોજેક્ટમાં લાઇબ્રેરી ઉમેરવા માટેની તકનીકી અને સૂચનાઓનું વર્ણન કરીશ નહીં, આ વિષય પર પૂરતા લેખો લખવામાં આવ્યા છે:

• સ્પ્રિંગ બૂટ એપ્લિકેશનમાં ડેટાબેઝ માળખું મેનેજ કરવા માટે લિક્વિબેઝનો ઉપયોગ કરવો. ભાગ 1
• સ્પ્રિંગ બૂટ એપ્લિકેશનમાં ડેટાબેઝ માળખું મેનેજ કરવા માટે લિક્વિબેઝનો ઉપયોગ કરવો. ભાગ 2
• લિક્વિબેઝ અને માવેન
• ડેટાબેઝના ફેરફારોની આવૃત્તિ માટેના અભિગમો
• સ્પ્રિંગ MVC/સુરક્ષા, REST, હાઇબરનેટ, લિક્વિબેઝ બે લાઇનમાં ચાલે છે

આ ઉપરાંત, ઉપયોગી ટીપ્સના વિષય પર પહેલેથી જ એક સરસ લેખ હતો:

• માથાનો દુખાવો વગર લિક્વિબેઝનો ઉપયોગ કરવો. વાસ્તવિક વિકાસ અનુભવમાંથી 10 ટીપ્સ

ટિપ્સ

હું મારી સલાહ અને ટિપ્પણીઓ શેર કરવા માંગુ છું, જેનો જન્મ પરસેવો, લોહી અને સ્થળાંતર સાથેની સમસ્યાઓના ઉકેલની પીડા દ્વારા થયો હતો.

1. શરૂ કરતા પહેલા, તમારે શ્રેષ્ઠ પ્રેક્ટિસ વિભાગ વાંચવો જોઈએ સાઇટ લિક્વિબેઝ

ત્યાં સરળ પરંતુ ખૂબ જ મહત્વપૂર્ણ વસ્તુઓનું વર્ણન કરવામાં આવ્યું છે, જેના વિના પુસ્તકાલયનો ઉપયોગ તમારા જીવનને જટિલ બનાવી શકે છે. ઉદાહરણ તરીકે, ચેન્જસેટ મેનેજમેન્ટ માટે બિન-માળખાકીય અભિગમ વહેલા કે પછીથી મૂંઝવણ અને તૂટેલા સ્થળાંતર તરફ દોરી જશે. જો તમે એક જ સમયે ડેટાબેઝની રચના અને સેવાઓના તર્કમાં પરસ્પર આધારિત ફેરફારોને રોલ આઉટ કરશો નહીં, તો ઉચ્ચ સંભાવના છે કે આ લાલ પરીક્ષણો અથવા તૂટેલા વાતાવરણ તરફ દોરી જશે. વધુમાં, સત્તાવાર વેબસાઇટ પર લિક્વિબેઝનો ઉપયોગ કરવા માટેની ભલામણોમાં મુખ્ય સ્થળાંતર સ્ક્રિપ્ટો સાથે રોલબેક સ્ક્રિપ્ટના વિકાસ અને ચકાસણી વિશેનો ફકરો છે. સારું, લેખમાં https://habr.com/ru/post/178665/ સ્થળાંતર અને રોલબેક મિકેનિઝમ સંબંધિત કોડના ઉદાહરણો છે.

2. જો તમે સ્થળાંતર સાધનોનો ઉપયોગ કરવાનું શરૂ કર્યું હોય, તો ડેટાબેઝ માળખામાં મેન્યુઅલ સુધારાને મંજૂરી આપશો નહીં

જેમ કહેવત છે: "એકવાર પર્સિલ, હંમેશા પર્સિલ." જો તમારી એપ્લિકેશનનો આધાર લિક્વિબેઝ ટૂલ્સ દ્વારા સંચાલિત થવાનું શરૂ થયું હોય, તો કોઈપણ મેન્યુઅલ ફેરફારો તરત જ અસંગત સ્થિતિ તરફ દોરી જાય છે, અને ચેન્જસેટ્સમાં વિશ્વાસનું સ્તર શૂન્ય બની જાય છે. સંભવિત જોખમો - ડેટાબેઝને પુનઃસ્થાપિત કરવામાં કેટલાક કલાકો વિતાવ્યા, સૌથી ખરાબ પરિસ્થિતિમાં - એક મૃત સર્વર. જો તમારી ટીમ પાસે "જૂની શાળા" DBA આર્કિટેક્ટ છે, તો તેને ધીરજપૂર્વક અને વિચારપૂર્વક સમજાવો કે જો તે માત્ર શરતી SQL ડેવલપર પાસેથી ડેટાબેઝને પોતાની રીતે સંપાદિત કરે તો વસ્તુઓ કેટલી ખરાબ હશે.

3. જો ચેન્જસેટ પહેલાથી જ રીપોઝીટરીમાં દબાણ કરવામાં આવ્યું હોય, તો સંપાદન કરવાનું ટાળો

જો બીજા ડેવલપરે ફેરફાર કરીને ફેરફાર કર્યો હોય અને તેને લાગુ કર્યો હોય, તો જ્યારે એપ્લિકેશન શરૂ થશે ત્યારે તેને ભૂલ આવશે ત્યારે તે તમને દયાળુ શબ્દ સાથે ચોક્કસપણે યાદ રાખશે. જો ચેન્જસેટને સંપાદિત કરવાથી વિકાસમાં કોઈક રીતે લીક થાય છે, તો તમારે હોટફિક્સના લપસણો ઢોળાવ નીચે જવું પડશે. સમસ્યાનો સાર હેશ સમ દ્વારા ફેરફારોની માન્યતા પર આધાર રાખે છે - લિક્વિબેઝની મુખ્ય પદ્ધતિ. ચેન્જસેટ કોડમાં ફેરફાર કરતી વખતે, હેશ સરવાળા બદલાય છે. ચેન્જસેટ્સનું સંપાદન ત્યારે જ શક્ય છે જ્યારે ડેટા ગુમાવ્યા વિના સમગ્ર ડેટાબેઝને શરૂઆતથી જમાવવાનું શક્ય હોય. આ કિસ્સામાં, એસક્યુએલ અથવા એક્સએમએલ કોડ રિફેક્ટીંગ, તેનાથી વિપરીત, જીવનને સરળ બનાવી શકે છે, સ્થળાંતરને વધુ વાંચવા યોગ્ય બનાવી શકે છે. ઉદાહરણ એ એવી પરિસ્થિતિ હશે જ્યારે, એપ્લિકેશનની શરૂઆતમાં, સ્રોત ડેટાબેઝની સ્કીમા ટીમની અંદર સંકલિત કરવામાં આવી હતી.

4. જો શક્ય હોય તો ચકાસાયેલ ડેટાબેઝ બેકઅપ રાખો

અહીં, મને લાગે છે, બધું સ્પષ્ટ છે. જો અચાનક સ્થળાંતર અસફળ હતું, તો બધું પાછું પાછું આપી શકાય છે. લિક્વિબેઝમાં રોલબેક ટૂલ છે, પરંતુ રોલબેક સ્ક્રિપ્ટો પણ ડેવલપર દ્વારા જ લખવામાં આવે છે, અને તેમને મુખ્ય ચેન્જસેટ સ્ક્રિપ્ટ્સની સમાન સંભાવના સાથે સમસ્યાઓ હોઈ શકે છે. આનો અર્થ એ છે કે તેને બેકઅપ સાથે સુરક્ષિત વગાડવું કોઈપણ સંજોગોમાં ઉપયોગી છે.

5. જો શક્ય હોય તો વિકાસમાં ચકાસાયેલ ડેટાબેઝ બેકઅપનો ઉપયોગ કરો

જો આ કરારો અને ગોપનીયતાનો વિરોધાભાસ કરતું નથી, તો ડેટાબેઝમાં કોઈ વ્યક્તિગત ડેટા નથી, અને તેનું વજન બે સૂર્યની જેમ નથી - તેને લાઇવ સ્થાનાંતરણ સર્વર્સ પર લાગુ કરતાં પહેલાં, તમે વિકાસકર્તાના મશીન પર તે કેવી રીતે કાર્ય કરે છે તે તપાસી શકો છો અને લગભગ 100% ગણતરી કરી શકો છો. સ્થળાંતર દરમિયાન સંભવિત સમસ્યાઓ.

6. ટીમમાં અન્ય વિકાસકર્તાઓ સાથે ચેટ કરો

સુવ્યવસ્થિત વિકાસ પ્રક્રિયામાં, ટીમમાં દરેક વ્યક્તિ જાણે છે કે કોણ શું કરી રહ્યું છે. વાસ્તવમાં, ઘણીવાર આવું થતું નથી, તેથી, જો તમે તમારા કાર્યના ભાગ રૂપે ડેટાબેઝ સ્ટ્રક્ચરમાં ફેરફારની તૈયારી કરી રહ્યાં છો, તો આ વિશે સમગ્ર ટીમને વધુમાં સૂચિત કરવાની સલાહ આપવામાં આવે છે. જો કોઈ સમાંતર ફેરફારો કરી રહ્યું હોય, તો તમારે કાળજીપૂર્વક ગોઠવવું જોઈએ. ફક્ત શરૂઆતમાં જ નહીં, કામના અંતે પણ સાથીદારો સાથે વાતચીત કરવી તે યોગ્ય છે. ચેન્જસેટ્સ સાથેની ઘણી સંભવિત સમસ્યાઓ કોડ સમીક્ષાના તબક્કે ઉકેલી શકાય છે.

7. વિચારો કે તમે શું કરી રહ્યા છો!

દેખીતી રીતે સ્વયં-સ્પષ્ટ સલાહ કોઈપણ પરિસ્થિતિને લાગુ પડે છે. જો કે, જો વિકાસકર્તાએ ફરી એકવાર વિશ્લેષણ કર્યું હોત કે તે શું કરી રહ્યો છે અને તેની શું અસર થઈ શકે છે, તો ઘણી સમસ્યાઓ ટાળી શકાઈ હોત. સ્થળાંતર સાથે કામ કરવા માટે હંમેશા વિશેષ ધ્યાન અને ચોકસાઈની જરૂર હોય છે.

ફાંસો

ચાલો હવે જોઈએ કે જો તમે ઉપરની સલાહને અનુસરતા નથી, તો તમે તેમાં ફસાઈ શકો છો, અને હકીકતમાં, શું કરવું જોઈએ?

પરિસ્થિતિ 1. બે વિકાસકર્તાઓ એક જ સમયે નવા ફેરફારો ઉમેરવાનો પ્રયાસ કરી રહ્યા છે

વાસ્યા અને પેટ્યા એકબીજા વિશે જાણ્યા વિના સંસ્કરણ 4 ચેન્જસેટ બનાવવા માંગે છે. તેઓએ ડેટાબેઝ સ્ટ્રક્ચરમાં ફેરફારો કર્યા, અને વિવિધ ચેન્જસેટ ફાઇલો સાથે પુલ રિક્વેસ્ટ રોલ આઉટ કરી. નીચેની મિકેનિઝમ નીચે સૂચિત છે:

કેવી રીતે ઉકેલવું

1. કોઈક રીતે, સહકર્મીઓએ તેમના ફેરફારો કયા ક્રમમાં જવા જોઈએ તેના પર સંમત થવું જોઈએ, ચાલો કહીએ કે પેટિનને પહેલા લાગુ કરવું જોઈએ.
2. એક વ્યક્તિએ બીજાને રેડવું જોઈએ અને વાસ્યના ચેન્જસેટને સંસ્કરણ 5 સાથે ચિહ્નિત કરવું જોઈએ. આ ચેરી પિક અથવા સુઘડ મર્જ દ્વારા કરી શકાય છે.
3. ફેરફારો કર્યા પછી, લેવામાં આવેલી ક્રિયાઓની માન્યતા તપાસવાની ખાતરી કરો.
   હકીકતમાં, લિક્વિબેઝ મિકેનિઝમ્સ તમને રીપોઝીટરીમાં બે સંસ્કરણ 4 ચેન્જસેટ્સ રાખવાની મંજૂરી આપશે, જેથી તમે બધું જેમ છે તેમ છોડી શકો. એટલે કે, તમારી પાસે વિવિધ નામો સાથે સંસ્કરણ 4 ના બે પુનરાવર્તનો હશે. આ અભિગમ સાથે, ડેટાબેઝ સંસ્કરણો પાછળથી નેવિગેટ કરવા માટે ખૂબ જ મુશ્કેલ બની જાય છે.

આ ઉપરાંત, લિક્વિબેઝ, હોબિટ્સના ઘરોની જેમ, ઘણા રહસ્યો રાખે છે. તેમાંથી એક validCheckSum કી છે, જે આવૃત્તિ 1.7 થી દેખાઈ છે અને ડેટાબેઝમાં શું સંગ્રહિત છે તે ધ્યાનમાં લીધા વિના, ચોક્કસ ચેન્જસેટ માટે તમને માન્ય હેશ મૂલ્યનો ઉલ્લેખ કરવાની મંજૂરી આપે છે. દસ્તાવેજીકરણ https://www.liquibase.org/documentation/changeset.html નીચેના કહે છે:

એક ચેકસમ ઉમેરો કે જે આ ચેન્જસેટ માટે માન્ય ગણવામાં આવે છે, ડેટાબેઝમાં શું સંગ્રહિત છે તે ધ્યાનમાં લીધા વગર. જ્યારે તમારે ચેન્જસેટ બદલવાની જરૂર હોય અને ડેટાબેસેસ કે જેના પર તે પહેલાથી જ ચાલે છે તેના પર ભૂલો નાખવા માંગતા નથી ત્યારે તેનો ઉપયોગ મુખ્યત્વે થાય છે (આગ્રહણીય પ્રક્રિયા નથી)

હા, આ આગ્રહણીય નથી. પરંતુ કેટલીકવાર મજબૂત પ્રકાશ જાદુગર પણ શ્યામ તકનીકોમાં નિપુણતા મેળવે છે.

કેસ 2: ડેટા-આધારિત સ્થળાંતર

ચાલો કહીએ કે તમે લાઇવ સર્વર્સમાંથી ડેટાબેઝ બેકઅપનો ઉપયોગ કરી શકતા નથી. પેટ્યાએ એક ચેન્જસેટ બનાવ્યો, સ્થાનિક રીતે તેનું પરીક્ષણ કર્યું અને તે સાચા હતા તેવા સંપૂર્ણ વિશ્વાસ સાથે, વિકાસકર્તાને પુલ વિનંતી કરી. ફક્ત કિસ્સામાં, પ્રોજેક્ટના નેતાએ સ્પષ્ટ કર્યું કે શું પેટ્યાએ તેને તપાસ્યું, અને પછી તેને રેડ્યું. પરંતુ ડેવલપમેન્ટ સર્વર પર જમાવટ ઘટી છે.

હકીકતમાં, આ શક્ય છે, અને કોઈ પણ આમાંથી પ્રતિરક્ષા નથી. જો ટેબલ સ્ટ્રક્ચરમાં ફેરફાર ડેટાબેઝના ચોક્કસ ડેટા સાથે કોઈક રીતે જોડાયેલા હોય તો આવું થાય છે. દેખીતી રીતે, જો પેટ્યાનો ડેટાબેઝ ફક્ત પરીક્ષણ ડેટાથી ભરેલો હોય, તો તે તમામ સમસ્યાના કેસોને આવરી શકશે નહીં. ઉદાહરણ તરીકે, કોષ્ટક કાઢી નાખતી વખતે, તે બહાર આવ્યું છે કે વિદેશી કી દ્વારા અન્ય કોષ્ટકોમાં રેકોર્ડ્સ છે જે કાઢી નાખવામાં આવતા રેકોર્ડ સાથે સંકળાયેલા છે. અથવા કૉલમનો પ્રકાર બદલતી વખતે, તે તારણ આપે છે કે 100% ડેટાને નવા પ્રકારમાં રૂપાંતરિત કરી શકાતો નથી.

કેવી રીતે ઉકેલવું

• ખાસ સ્ક્રિપ્ટો લખો જે સ્થળાંતર સાથે એકવાર લાગુ થશે અને ડેટાને યોગ્ય સ્વરૂપમાં લાવો. સ્થળાંતર લાગુ કર્યા પછી ડેટાને નવા સ્ટ્રક્ચર્સમાં સ્થાનાંતરિત કરવાની સમસ્યાને હલ કરવાની આ એક સામાન્ય રીત છે, પરંતુ ખાસ કિસ્સાઓમાં, તે પહેલાં કંઈક સમાન લાગુ કરી શકાય છે. આ પાથ, અલબત્ત, હંમેશા ઉપલબ્ધ નથી, કારણ કે લાઇવ સર્વર્સ પર ડેટા સંપાદિત કરવું જોખમી અને જીવલેણ પણ હોઈ શકે છે.
• હાલના ચેન્જસેટને સંપાદિત કરવાની બીજી મુશ્કેલ રીત છે. મુશ્કેલી એ છે કે તમામ ડેટાબેસેસ જ્યાં તે તેના હાલના સ્વરૂપમાં લાગુ કરવામાં આવ્યા છે તે પુનઃસ્થાપિત કરવા પડશે. તે તદ્દન શક્ય છે કે સમગ્ર બેકએન્ડ ટીમને શરૂઆતથી ડેટાબેઝને સ્થાનિક રીતે રોલ અપ કરવાની ફરજ પાડવામાં આવશે.
• અને સૌથી સાર્વત્રિક રીત એ છે કે ડેટા સમસ્યાને વિકાસકર્તાના પર્યાવરણમાં સ્થાનાંતરિત કરવી, તે જ પરિસ્થિતિને ફરીથી બનાવવી અને તૂટેલામાં નવો ચેન્જસેટ ઉમેરવાનો, જે સમસ્યાને બાયપાસ કરશે.
  

સામાન્ય રીતે, ઉત્પાદન સર્વર ડેટાબેઝની રચનામાં ડેટાબેઝ જેટલો વધુ સમાન છે, સ્થળાંતર સાથેની સમસ્યાઓ દૂર થવાની શક્યતા ઓછી છે. અને, અલબત્ત, તમે રીપોઝીટરીમાં ચેન્જસેટ મોકલો તે પહેલાં, તમારે ઘણી વખત વિચારવું જોઈએ કે શું તે કંઈક તૂટી જશે.

સિચ્યુએશન 3. લિક્વિબેઝ ઉત્પાદનમાં જાય પછી તેનો ઉપયોગ શરૂ થાય છે

ધારો કે ટીમના નેતાએ પેટ્યાને લિક્વિબેઝને પ્રોજેક્ટમાં સામેલ કરવા કહ્યું, પરંતુ પ્રોજેક્ટ પહેલેથી જ ઉત્પાદનમાં છે અને ત્યાં પહેલેથી જ અસ્તિત્વમાં છે તે ડેટાબેઝ માળખું છે.

તદનુસાર, સમસ્યા એ છે કે કોઈપણ નવા સર્વર્સ અથવા વિકાસકર્તા મશીનો પર, ટેબલ ડેટાને શરૂઆતથી ફરીથી બનાવવો જોઈએ, અને પહેલાથી અસ્તિત્વમાં છે તે વાતાવરણ સતત સ્થિતિમાં રહેવું જોઈએ, નવા ફેરફારો સ્વીકારવા માટે તૈયાર છે.

કેવી રીતે ઉકેલવું

ત્યાં પણ ઘણી રીતો છે:

• પ્રથમ અને સૌથી વધુ સ્પષ્ટ એ છે કે એક અલગ સ્ક્રિપ્ટ હોવી જોઈએ જે નવા પર્યાવરણને પ્રારંભ કરતી વખતે મેન્યુઅલી લાગુ થવી જોઈએ.
• બીજું, ઓછું સ્પષ્ટ છે, લિક્વિબેઝ સ્થળાંતર કરવું કે જે અલગ લિક્વિબેઝ સંદર્ભમાં છે અને તેને લાગુ કરો. તમે અહીં લિક્વિબેઝ સંદર્ભ વિશે વધુ વાંચી શકો છો: https://www.liquibase.org/documentation/contexts.html. સામાન્ય રીતે, આ એક રસપ્રદ પદ્ધતિ છે જે સફળતાપૂર્વક લાગુ કરી શકાય છે, ઉદાહરણ તરીકે, પરીક્ષણ માટે.
• ત્રીજો માર્ગ અનેક પગલાઓનો સમાવેશ કરે છે. પ્રથમ, હાલના કોષ્ટકો માટે સ્થળાંતર બનાવવું આવશ્યક છે. પછી તેને અમુક પર્યાવરણ પર લાગુ કરવું આવશ્યક છે અને આ રીતે તેનો હેશ સમ પ્રાપ્ત થશે. આગળનું પગલું એ અમારા બિન-ખાલી સર્વર પર ખાલી લિક્વિબેઝ કોષ્ટકોને પ્રારંભ કરવાનું છે, અને તમે ફેરફારોને લાગુ કરવાના ઇતિહાસ સાથેના કોષ્ટકમાં ડેટાબેઝમાં પહેલાથી જ થયેલા ફેરફારો સાથે "જેમ લાગુ કરો છો" ફેરફારોનો રેકોર્ડ મેન્યુઅલી મૂકી શકો છો. આમ, પહેલાથી અસ્તિત્વમાં રહેલા સર્વર પર, ઇતિહાસ સંસ્કરણ 2 થી શરૂ થશે, અને તમામ નવા વાતાવરણ સમાન રીતે વર્તે છે.
  

દૃશ્ય 4: સ્થળાંતર મોટા પ્રમાણમાં થાય છે અને ચાલુ રાખી શકતા નથી

સેવા વિકાસની શરૂઆતમાં, એક નિયમ તરીકે, લિક્વિબેઝનો ઉપયોગ બાહ્ય નિર્ભરતા તરીકે થાય છે, અને જ્યારે એપ્લિકેશન શરૂ થાય છે ત્યારે તમામ સ્થળાંતર પર પ્રક્રિયા કરવામાં આવે છે. જો કે, સમય જતાં, તમે નીચેના કેસોમાં ઠોકર ખાઈ શકો છો:

• સ્થળાંતર વિશાળ બને છે અને પૂર્ણ થવામાં લાંબો સમય લે છે.
• વિતરિત વાતાવરણમાં સ્થળાંતર કરવાની જરૂર છે, ઉદાહરણ તરીકે, એક જ સમયે ડેટાબેઝ સર્વર્સના ઘણા ઉદાહરણો પર.
  આ કિસ્સામાં, ખૂબ લાંબા સમય માટે સ્થળાંતર લાગુ કરવાથી એપ્લિકેશન શરૂ થાય ત્યારે સમય સમાપ્ત થશે. ઉપરાંત, પ્રતિ એપ્લીકેશન ઇન્સ્ટન્સના આધારે સ્થળાંતર લાગુ કરવાથી વિવિધ સર્વર્સ સમન્વયની બહારની સ્થિતિમાં હોઈ શકે છે.

કેવી રીતે ઉકેલવું

આવા કિસ્સાઓમાં, તમારો પ્રોજેક્ટ પહેલેથી જ મોટો છે, કદાચ પુખ્ત વયનો પણ, અને Liquibase એક અલગ બાહ્ય સાધન તરીકે કાર્ય કરવાનું શરૂ કરે છે. હકીકત એ છે કે લિક્વિબેઝ, લાઇબ્રેરી તરીકે, જાર ફાઇલમાં એસેમ્બલ થાય છે, અને પ્રોજેક્ટની અંદર નિર્ભરતા તરીકે કામ કરી શકે છે, તેમજ એકલ.

ઑફલાઇન, તમે તમારા CI/CD વાતાવરણમાં અથવા તમારા sysadmins/deployers ના મજબૂત ખભા પર સ્થળાંતરની અરજી છોડી શકો છો. આ કરવા માટે, તમારે લિક્વિબેઝ કમાન્ડ લાઇનની જરૂર છે https://www.liquibase.org/documentation/command_line.html. આ મોડમાં, તમામ જરૂરી સ્થળાંતર પૂર્ણ થયા પછી એપ્લિકેશન શરૂ કરવાનું શક્ય બને છે.

નિષ્કર્ષ

હકીકતમાં, ડેટાબેઝ સ્થળાંતર સાથે કામ કરતી વખતે ઘણી બધી મુશ્કેલીઓ છે, અને તેમાંના ઘણાને સર્જનાત્મક અભિગમની જરૂર છે. તે સમજવું અગત્યનું છે કે જો તમે સાધનનો યોગ્ય રીતે ઉપયોગ કરો છો, તો આમાંથી મોટા ભાગના ફાંસો ટાળી શકાય છે. ખાસ કરીને, મને વિવિધ સ્વરૂપોમાં સૂચિબદ્ધ બધી સમસ્યાઓનો સામનો કરવો પડ્યો હતો, અને તેમાંના કેટલાક મારા જામનું પરિણામ હતા. મૂળભૂત રીતે, આવું થાય છે, અલબત્ત, બેદરકારીને કારણે, પરંતુ કેટલીકવાર - સાધનનો ઉપયોગ કરવામાં ગુનાહિત અસમર્થતાને કારણે.

સોર્સ: www.habr.com