ఇంతకు ముందెన్నడూ జరగలేదు మరియు ఇక్కడ మేము మళ్ళీ వెళ్తాము!
మా తదుపరి ప్రాజెక్ట్‌లో, భవిష్యత్తులో సమస్యలను నివారించడానికి మేము మొదటి నుండి లిక్విబేస్‌ని ఉపయోగించాలని నిర్ణయించుకున్నాము. ఇది ముగిసినట్లుగా, యువ జట్టు సభ్యులందరికీ దీన్ని సరిగ్గా ఎలా ఉపయోగించాలో తెలియదు. నేను ఒక అంతర్గత వర్క్‌షాప్‌ను నిర్వహించాను, దానిని నేను వ్యాసంగా మార్చాలని నిర్ణయించుకున్నాను.
వ్యాసంలో ఉపయోగకరమైన చిట్కాలు మరియు రిలేషనల్ డేటాబేస్ మైగ్రేషన్ టూల్స్, ప్రత్యేకించి లిక్విబేస్‌తో పనిచేసేటప్పుడు మీరు పడే మూడు అత్యంత స్పష్టమైన ఆపదల వివరణ ఉన్నాయి. జూనియర్ మరియు మిడిల్ స్థాయిలలో జావా డెవలపర్‌ల కోసం రూపొందించబడింది; మరింత అనుభవజ్ఞులైన డెవలపర్‌లకు ఇది ఇప్పటికే తెలిసిన వాటిని రూపొందించడానికి మరియు పునరావృతం చేయడానికి ఆసక్తిని కలిగిస్తుంది.
లిక్విబేస్ మరియు ఫ్లైవే జావా ప్రపంచంలో రిలేషనల్ స్ట్రక్చర్ల వెర్షన్ నియంత్రణ సమస్యలను పరిష్కరించడానికి ప్రధాన పోటీ సాంకేతికతలు. మొదటిది పూర్తిగా ఉచితం, ఆచరణలో ఇది చాలా తరచుగా ఉపయోగం కోసం ఎంపిక చేయబడుతుంది, అందుకే లిక్విబేస్ ప్రచురణ యొక్క హీరోగా ఎంపిక చేయబడింది. అయితే, మీ అప్లికేషన్ ఆర్కిటెక్చర్‌పై ఆధారపడి వివరించిన కొన్ని అభ్యాసాలు సార్వత్రికమైనవి కావచ్చు.
రిలేషనల్ డేటా స్టోర్‌ల బలహీనమైన సౌలభ్యాన్ని ఎదుర్కోవడానికి రిలేషనల్ స్ట్రక్చర్ల మైగ్రేషన్‌లు బలవంతపు మార్గం. OOP ఫ్యాషన్ యుగంలో, డేటాబేస్‌లతో పని చేసే శైలి అంటే మనం స్కీమాను ఒకసారి వివరిస్తాము మరియు దానిని మళ్లీ తాకకూడదు. కానీ వాస్తవికత ఎల్లప్పుడూ విషయాలు మారుతూ ఉంటాయి మరియు పట్టిక నిర్మాణంలో మార్పులు చాలా తరచుగా అవసరమవుతాయి. సహజంగానే, ప్రక్రియ బాధాకరమైనది మరియు అసహ్యకరమైనది కావచ్చు.
మీ ప్రాజెక్ట్‌కి లైబ్రరీని జోడించడం కోసం సాంకేతికత మరియు సూచనల వివరణకు నేను లోతుగా వెళ్లను; ఈ అంశంపై చాలా కొన్ని కథనాలు వ్రాయబడ్డాయి:
అదనంగా, ఉపయోగకరమైన చిట్కాల అంశంపై ఇప్పటికే అద్భుతమైన కథనం ఉంది:
చిట్కాలు
వలసలతో సమస్యలను పరిష్కరించడంలో చెమట, రక్తం మరియు బాధ ద్వారా పుట్టిన నా సలహాలు మరియు వ్యాఖ్యలను పంచుకోవాలనుకుంటున్నాను.
1. పనిని ప్రారంభించే ముందు, మీరు ఉత్తమ అభ్యాసాల విభాగంతో మిమ్మల్ని పరిచయం చేసుకోవాలి లిక్విబేస్
సరళమైన కానీ చాలా ముఖ్యమైన విషయాలు వివరించబడ్డాయి, ఇది లేకుండా లైబ్రరీని ఉపయోగించడం మీ జీవితాన్ని క్లిష్టతరం చేస్తుంది. ఉదాహరణకు, మార్పులను నిర్వహించడానికి నిర్మాణాత్మకమైన విధానం త్వరగా లేదా తరువాత గందరగోళం మరియు విరిగిన వలసలకు దారి తీస్తుంది. మీరు అదే సమయంలో డేటాబేస్ నిర్మాణం మరియు సేవా తర్కంలో పరస్పరం ఆధారపడిన మార్పులను రోల్ చేయకపోతే, ఇది ఎరుపు పరీక్షలు లేదా విరిగిన వాతావరణానికి దారితీసే అధిక సంభావ్యత ఉంది. అదనంగా, అధికారిక వెబ్‌సైట్‌లో లిక్విబేస్‌ని ఉపయోగించడం కోసం సిఫార్సులు ప్రధాన మైగ్రేషన్ స్క్రిప్ట్‌లతో పాటు రోల్‌బ్యాక్ స్క్రిప్ట్‌ల అభివృద్ధి మరియు పరీక్ష గురించి ఒక నిబంధనను కలిగి ఉంటాయి. బాగా, వ్యాసంలో వలసలు మరియు రోల్‌బ్యాక్ మెకానిజంకు సంబంధించి కోడ్ ఉదాహరణలు ఉన్నాయి.
2. మీరు మైగ్రేషన్ సాధనాలను ఉపయోగించడం ప్రారంభించినట్లయితే, డేటాబేస్ నిర్మాణంలో మాన్యువల్ సవరణలను అనుమతించవద్దు
సామెత చెప్పినట్లుగా: "ఒకసారి పెర్సిల్, ఎల్లప్పుడూ పెర్సిల్." మీ అప్లికేషన్ యొక్క బేస్ Liquibase ద్వారా నిర్వహించబడటం ప్రారంభిస్తే, ఏదైనా మాన్యువల్ మార్పులు వెంటనే అస్థిర స్థితికి దారితీస్తాయి మరియు మార్పులపై విశ్వాసం స్థాయి సున్నా అవుతుంది. సంభావ్య ప్రమాదాలలో డేటాబేస్ను పునరుద్ధరించడానికి అనేక గంటలు గడిపారు; చెత్త దృష్టాంతంలో, డెడ్ సర్వర్. మీరు మీ బృందంలో "పాత పాఠశాల" DBA ఆర్కిటెక్ట్‌ని కలిగి ఉన్నట్లయితే, అతను షరతులతో కూడిన SQL డెవలపర్ నుండి తన స్వంత అవగాహన ప్రకారం డేటాబేస్ను సవరించినట్లయితే ఎంత చెడు విషయాలు జరుగుతాయో ఓపికగా మరియు ఆలోచనాత్మకంగా అతనికి వివరించండి.
3. మార్పుసెట్ ఇప్పటికే రిపోజిటరీలోకి నెట్టబడి ఉంటే, సవరణను నివారించండి
మరొక డెవలపర్ పుల్ చేసి, మార్పు సెట్‌ను వర్తింపజేస్తే, అది తరువాత సవరించబడుతుంది, అతను అప్లికేషన్‌ను ప్రారంభించేటప్పుడు లోపం వచ్చినప్పుడు అతను ఖచ్చితంగా మిమ్మల్ని మంచి పదంతో గుర్తుంచుకుంటాడు. మార్పుల సెట్‌ని సవరించడం వల్ల డెవలప్‌మెంట్‌లో లీక్ అయితే, మీరు హాట్‌ఫిక్స్‌ల జారే వాలును అనుసరించాల్సి ఉంటుంది. లిక్విబేస్ యొక్క ప్రధాన మెకానిజం - హాష్ సమ్ ద్వారా మార్పుల ధ్రువీకరణపై సమస్య యొక్క సారాంశం ఆధారపడి ఉంటుంది. మార్పుల కోడ్‌ను సవరించేటప్పుడు, హాష్ మొత్తం మారుతుంది. డేటాను కోల్పోకుండా మొత్తం డేటాబేస్ను మొదటి నుండి అమలు చేయడం సాధ్యమైనప్పుడు మాత్రమే మార్పులను సవరించడం సాధ్యమవుతుంది. ఈ సందర్భంలో, SQL లేదా XML కోడ్‌ని రీఫ్యాక్టరింగ్ చేయడం, దీనికి విరుద్ధంగా, జీవితాన్ని సులభతరం చేస్తుంది మరియు వలసలను మరింత చదవగలిగేలా చేస్తుంది. అప్లికేషన్ ప్రారంభంలో, సోర్స్ డేటాబేస్ యొక్క స్కీమా బృందంలో అంగీకరించబడిన పరిస్థితిని ఉదాహరణగా చెప్పవచ్చు.
4. వీలైతే ధృవీకరించబడిన డేటాబేస్ బ్యాకప్‌లను కలిగి ఉండండి
ఇక్కడ, నేను అనుకుంటున్నాను, ప్రతిదీ స్పష్టంగా ఉంది. అకస్మాత్తుగా వలస విఫలమైతే, ప్రతిదీ తిరిగి పొందవచ్చు. లిక్విబేస్‌లో మార్పులను రోలింగ్ బ్యాక్ చేయడానికి ఒక సాధనం ఉంది, అయితే రోల్‌బ్యాక్ స్క్రిప్ట్‌లు కూడా డెవలపర్‌చే వ్రాయబడతాయి మరియు అవి ప్రధాన మార్పుల స్క్రిప్ట్‌ల మాదిరిగానే అదే సంభావ్యతతో సమస్యలను కలిగి ఉంటాయి. ఏ సందర్భంలోనైనా బ్యాకప్‌లతో సురక్షితంగా ప్లే చేయడం ఉపయోగకరంగా ఉంటుందని దీని అర్థం.
5. సాధ్యమైతే, అభివృద్ధిలో నిరూపితమైన డేటాబేస్ బ్యాకప్‌లను ఉపయోగించండి
ఇది ఒప్పందాలు మరియు గోప్యతకు విరుద్ధంగా లేకపోతే, డేటాబేస్‌లో వ్యక్తిగత డేటా లేదు మరియు దాని బరువు రెండు సూర్యుల బరువు ఉండదు - లైవ్ మైగ్రేషన్ సర్వర్‌లలో ఉపయోగించే ముందు, డెవలపర్ మెషీన్‌లో ఇది ఎలా పని చేస్తుందో మీరు తనిఖీ చేయవచ్చు మరియు లెక్కించవచ్చు. వలస సమయంలో దాదాపు 100% సంభావ్య సమస్యలు.
6. బృందంలోని ఇతర డెవలపర్‌లతో కమ్యూనికేట్ చేయండి
బాగా వ్యవస్థీకృత అభివృద్ధి ప్రక్రియలో, ఎవరు ఏమి చేస్తున్నారో బృందంలోని ప్రతి ఒక్కరికీ తెలుసు. వాస్తవానికి, ఇది తరచుగా జరగదు, కాబట్టి, మీరు మీ పనిలో భాగంగా డేటాబేస్ నిర్మాణంలో మార్పులను సిద్ధం చేస్తుంటే, దీని గురించి మొత్తం బృందానికి అదనంగా తెలియజేయడం మంచిది. ఎవరైనా సమాంతరంగా మార్పులు చేస్తుంటే, మీరు జాగ్రత్తగా నిర్వహించాలి. పనిని పూర్తి చేసిన తర్వాత, ప్రారంభంలోనే కాకుండా సహోద్యోగులతో కమ్యూనికేట్ చేయడం విలువైనది. మార్పులతో అనేక సంభావ్య సమస్యలు కోడ్ సమీక్ష దశలో పరిష్కరించబడతాయి.
7. మీరు ఏమి చేస్తున్నారో ఆలోచించండి!
ఇది ఏదైనా పరిస్థితికి వర్తించే స్వీయ-స్పష్టమైన సలహాలా కనిపిస్తుంది. అయితే, డెవలపర్ అతను ఏమి చేస్తున్నాడో మరియు దాని ప్రభావం ఏమిటో మరోసారి విశ్లేషించినట్లయితే అనేక సమస్యలను నివారించవచ్చు. వలసలతో పని చేయడానికి ఎల్లప్పుడూ అదనపు శ్రద్ధ మరియు ఖచ్చితత్వం అవసరం.
ఎరలు
మీరు పైన ఉన్న సలహాను పాటించకపోతే మీరు పడే సాధారణ ఉచ్చులను ఇప్పుడు చూద్దాం మరియు మీరు ఖచ్చితంగా ఏమి చేయాలి?
పరిస్థితి 1: ఇద్దరు డెవలపర్‌లు ఒకే సమయంలో కొత్త మార్పులను జోడించడానికి ప్రయత్నిస్తున్నారు
వాస్య మరియు పెట్యా ఒకరికొకరు తెలియకుండానే మార్పుల వెర్షన్ 4ని సృష్టించాలనుకుంటున్నారు. వారు డేటాబేస్ నిర్మాణంలో మార్పులు చేసారు మరియు వివిధ మార్పు సెట్ ఫైల్‌లతో పుల్ అభ్యర్థనను జారీ చేశారు. చర్య యొక్క క్రింది విధానం ప్రతిపాదించబడింది:
ఎలా నిర్ణయించుకోవాలి
- ఏదో ఒకవిధంగా, సహోద్యోగులు వారి మార్పులను ఏ క్రమంలో వెళ్లాలి, ఉదాహరణకు, పెటిన్‌ను ముందుగా వర్తింపజేయాలి.
- ఎవరైనా రెండవ దాన్ని జోడించి, వాస్య మార్పులను వెర్షన్ 5తో గుర్తు పెట్టుకోవాలి. ఇది చెర్రీ పిక్ లేదా చక్కని విలీనం ద్వారా చేయవచ్చు.
- మార్పుల తర్వాత, మీరు ఖచ్చితంగా తీసుకున్న చర్యల చెల్లుబాటును తనిఖీ చేయాలి.
వాస్తవానికి, లిక్విబేస్ మెకానిజమ్స్ రిపోజిటరీలో రెండు వెర్షన్ 4 మార్పులను కలిగి ఉండటానికి మిమ్మల్ని అనుమతిస్తుంది, కాబట్టి మీరు ప్రతిదీ అలాగే ఉంచవచ్చు. అంటే, మీరు వేర్వేరు పేర్లతో వెర్షన్ 4కి రెండు మార్పులను కలిగి ఉంటారు. ఈ విధానంతో, తరువాత డేటాబేస్ సంస్కరణలను నావిగేట్ చేయడం చాలా కష్టమవుతుంది.
అదనంగా, లిక్విబేస్, హాబిట్‌ల నివాసం వలె, అనేక రహస్యాలను ఉంచుతుంది. వాటిలో ఒకటి చెల్లుబాటు అయ్యే చెక్‌సమ్ కీ, ఇది వెర్షన్ 1.7లో కనిపించింది మరియు డేటాబేస్‌లో నిల్వ చేయబడిన దానితో సంబంధం లేకుండా నిర్దిష్ట మార్పుల కోసం చెల్లుబాటు అయ్యే హాష్ విలువను పేర్కొనడానికి మిమ్మల్ని అనుమతిస్తుంది. డాక్యుమెంటేషన్ ఈ క్రింది వాటిని చెప్పారు:
డేటాబేస్‌లో నిల్వ చేయబడిన దానితో సంబంధం లేకుండా, ఈ చేంజ్‌సెట్ కోసం చెల్లుబాటు అయ్యేదిగా పరిగణించబడే చెక్‌సమ్‌ను జోడించండి. మీరు చేంజ్‌సెట్‌ని మార్చాల్సిన అవసరం వచ్చినప్పుడు మరియు ఇది ఇప్పటికే అమలు చేయబడిన డేటాబేస్‌లపై ఎర్రర్‌లు వద్దు (సిఫార్సు చేయబడిన విధానం కాదు)
అవును, అవును, ఈ విధానం సిఫారసు చేయబడలేదు. కానీ కొన్నిసార్లు ఒక బలమైన కాంతి మాంత్రికుడు కూడా డార్క్ టెక్నిక్లను మాస్టర్స్ చేస్తాడు
పరిస్థితి 2: డేటాపై ఆధారపడిన వలస
లైవ్ సర్వర్‌ల నుండి డేటాబేస్ బ్యాకప్‌లను ఉపయోగించగల సామర్థ్యం మీకు లేదని అనుకుందాం. పెట్యా ఒక మార్పు సెట్‌ని సృష్టించి, స్థానికంగా పరీక్షించి, అతను సరైనదేనని పూర్తి విశ్వాసంతో, డెవలపర్‌కి పుల్ అభ్యర్థన చేసాడు. ఒకవేళ, పెట్యా దాన్ని తనిఖీ చేసి, ఆపై జోడించిందో లేదో ప్రాజెక్ట్ లీడ్ స్పష్టం చేసింది. కానీ డెవలప్‌మెంట్ సర్వర్‌లో విస్తరణ పడిపోయింది.
వాస్తవానికి, ఇది సాధ్యమే, మరియు దీని నుండి ఎవరూ రక్షింపబడరు. పట్టిక నిర్మాణంలో మార్పులు ఏదో ఒకవిధంగా డేటాబేస్ నుండి నిర్దిష్ట డేటాతో ముడిపడి ఉంటే ఇది జరుగుతుంది. సహజంగానే, పెట్యా యొక్క డేటాబేస్ పరీక్ష డేటాతో మాత్రమే నిండి ఉంటే, అది అన్ని సమస్య కేసులను కవర్ చేయకపోవచ్చు. ఉదాహరణకు, పట్టికను తొలగిస్తున్నప్పుడు, ఇతర పట్టికలలో ఫారిన్ కీ ద్వారా తొలగించబడే రికార్డులకు సంబంధించిన రికార్డులు ఉన్నాయని తేలింది. లేదా కాలమ్ రకాన్ని మార్చినప్పుడు, డేటాలో 100% కొత్త రకానికి మార్చబడదని తేలింది.
ఎలా నిర్ణయించుకోవాలి
- మైగ్రేషన్‌తో పాటు ఒకసారి ఉపయోగించబడే ప్రత్యేక స్క్రిప్ట్‌లను వ్రాయండి మరియు డేటాను సరైన రూపంలోకి తీసుకురండి. వలసలను వర్తింపజేసిన తర్వాత కొత్త నిర్మాణాలకు డేటాను బదిలీ చేయడంలో సమస్యను పరిష్కరించడానికి ఇది ఒక సాధారణ మార్గం, కానీ ప్రత్యేక సందర్భాలలో ఇలాంటిదే ఏదైనా ముందు వర్తించవచ్చు. ఈ మార్గం, వాస్తవానికి, ఎల్లప్పుడూ అందుబాటులో ఉండదు, ఎందుకంటే లైవ్ సర్వర్‌లలో డేటాను సవరించడం ప్రమాదకరమైనది మరియు వినాశకరమైనది కూడా కావచ్చు.
- ఇప్పటికే ఉన్న మార్పులను సవరించడం మరొక కష్టమైన మార్గం. ఇబ్బంది ఏమిటంటే, ఇది ఇప్పటికే ఉన్న రూపంలో ఇప్పటికే వర్తించబడిన అన్ని డేటాబేస్‌లను పునరుద్ధరించవలసి ఉంటుంది. మొత్తం బ్యాకెండ్ బృందం మొదటి నుండి డేటాబేస్ను స్థానికంగా రూపొందించడానికి బలవంతం చేయబడే అవకాశం ఉంది.
- మరియు అత్యంత సార్వత్రిక మార్గం ఏమిటంటే, డెవలపర్ యొక్క వాతావరణానికి డేటాతో సమస్యను బదిలీ చేయడం, అదే పరిస్థితిని పునఃసృష్టించడం మరియు విరిగిన దానికి కొత్త మార్పులను జోడించడం, ఇది సమస్యను తప్పించుకుంటుంది.
సాధారణంగా, డేటాబేస్ ఉత్పత్తి సర్వర్ డేటాబేస్‌తో కూడిన కూర్పులో ఎంత ఎక్కువగా ఉంటే, వలసలతో సమస్యలు చాలా తక్కువగా ఉండే అవకాశం ఉంది. మరియు, వాస్తవానికి, మీరు రిపోజిటరీకి మార్పులను పంపే ముందు, అది ఏదైనా విచ్ఛిన్నం అవుతుందా అని మీరు చాలాసార్లు ఆలోచించాలి.
పరిస్థితి 3. లిక్విబేస్ ఉత్పత్తికి వెళ్ళిన తర్వాత ఉపయోగించడం ప్రారంభమవుతుంది
ప్రాజెక్ట్‌లో లిక్విబేస్‌ను చేర్చమని టీమ్ లీడ్ పెట్యాను కోరిందని అనుకుందాం, అయితే ప్రాజెక్ట్ ఇప్పటికే ఉత్పత్తిలో ఉంది మరియు ఇప్పటికే డేటాబేస్ నిర్మాణం ఉంది.
దీని ప్రకారం, సమస్య ఏమిటంటే, ఏదైనా కొత్త సర్వర్లు లేదా డెవలపర్ మెషీన్‌లలో, ఈ పట్టికలు మొదటి నుండి పునఃసృష్టి చేయబడాలి మరియు ఇప్పటికే ఉన్న పర్యావరణం స్థిరమైన స్థితిలో ఉండాలి, కొత్త మార్పులను అంగీకరించడానికి సిద్ధంగా ఉండాలి.
ఎలా నిర్ణయించుకోవాలి
అనేక మార్గాలు కూడా ఉన్నాయి:
- కొత్త వాతావరణాన్ని ప్రారంభించేటప్పుడు మాన్యువల్‌గా వర్తింపజేయవలసిన ప్రత్యేక స్క్రిప్ట్‌ను కలిగి ఉండటం మొదటి మరియు అత్యంత స్పష్టమైనది.
- రెండవది తక్కువ స్పష్టంగా ఉంది, మరొక లిక్విబేస్ సందర్భంలో ఉన్న లిక్విబేస్ మైగ్రేషన్‌ను కలిగి ఉండి, దానిని వర్తింపజేయండి. లిక్విబేస్ సందర్భం గురించి మీరు ఇక్కడ మరింత చదువుకోవచ్చు: . సాధారణంగా, ఇది ఒక ఆసక్తికరమైన యంత్రాంగం, ఇది విజయవంతంగా ఉపయోగించబడుతుంది, ఉదాహరణకు, పరీక్ష కోసం.
- మూడవ మార్గం అనేక దశలను కలిగి ఉంటుంది. ముందుగా, ఇప్పటికే ఉన్న పట్టికల కోసం తప్పనిసరిగా మైగ్రేషన్ సృష్టించబడాలి. అప్పుడు అది తప్పనిసరిగా కొన్ని పర్యావరణానికి వర్తింపజేయాలి మరియు తద్వారా దాని హాష్ మొత్తం పొందబడుతుంది. తదుపరి దశ మా నాన్-ఖాళీ సర్వర్‌లో ఖాళీ లిక్విబేస్ పట్టికలను ప్రారంభించడం మరియు మార్పుసెట్‌ల వినియోగ చరిత్రతో కూడిన పట్టికలో, మీరు డేటాబేస్‌లో ఇప్పటికే ఉన్న మార్పులతో “వర్తింపజేసినట్లుగా” మార్పుల గురించి మాన్యువల్‌గా రికార్డ్ చేయవచ్చు. . అందువల్ల, ఇప్పటికే ఉన్న సర్వర్‌లో, చరిత్ర కౌంట్‌డౌన్ వెర్షన్ 2 నుండి ప్రారంభమవుతుంది మరియు అన్ని కొత్త పరిసరాలు ఒకేలా ప్రవర్తిస్తాయి.
పరిస్థితి 4. వలసలు భారీగా మారతాయి మరియు పూర్తి చేయడానికి సమయం లేదు
సేవా అభివృద్ధి ప్రారంభంలో, ఒక నియమం వలె, లిక్విబేస్ బాహ్య డిపెండెన్సీగా ఉపయోగించబడుతుంది మరియు అప్లికేషన్ ప్రారంభమైనప్పుడు అన్ని వలసలు ప్రాసెస్ చేయబడతాయి. అయితే, కాలక్రమేణా, మీరు ఈ క్రింది సందర్భాలలో పొరపాట్లు చేయవచ్చు:
- వలసలు భారీగా మారతాయి మరియు పూర్తి కావడానికి చాలా సమయం పడుతుంది.
- పంపిణీ చేయబడిన పరిసరాలలో మైగ్రేషన్ అవసరం ఉంది, ఉదాహరణకు, అనేక డేటాబేస్ సర్వర్ సందర్భాలలో ఏకకాలంలో.
ఈ సందర్భంలో, చాలా కాలం పాటు మైగ్రేషన్‌లను వర్తింపజేయడం వలన అప్లికేషన్ ప్రారంభమైనప్పుడు గడువు ముగిసింది. అదనంగా, ప్రతి అప్లికేషన్ ఉదాహరణకి విడివిడిగా మైగ్రేషన్‌లను వర్తింపజేయడం వలన వివిధ సర్వర్లు సమకాలీకరించబడవు.
ఎలా నిర్ణయించుకోవాలి
అటువంటి సందర్భాలలో, మీ ప్రాజెక్ట్ ఇప్పటికే పెద్దది, బహుశా పెద్దలు కూడా కావచ్చు మరియు Liquibase ప్రత్యేక బాహ్య సాధనంగా పని చేయడం ప్రారంభిస్తుంది. వాస్తవం ఏమిటంటే లైబ్రరీగా లిక్విబేస్ ఒక జార్ ఫైల్‌గా కంపైల్ చేయబడింది మరియు ప్రాజెక్ట్‌లో లేదా స్వతంత్రంగా డిపెండెన్సీగా పని చేస్తుంది.
స్వతంత్ర మోడ్‌లో, మీరు మీ CI/CD వాతావరణానికి లేదా మీ సిస్టమ్ అడ్మినిస్ట్రేటర్‌లు మరియు విస్తరణ నిపుణుల బలమైన భుజాలకు మైగ్రేషన్‌ల అమలును వదిలివేయవచ్చు. దీన్ని చేయడానికి మీకు Liquibase కమాండ్ లైన్ అవసరం . ఈ మోడ్‌లో, అవసరమైన అన్ని మైగ్రేషన్‌లు పూర్తయిన తర్వాత అప్లికేషన్‌ను ప్రారంభించడం సాధ్యమవుతుంది.
తీర్మానం
నిజానికి, డేటాబేస్ మైగ్రేషన్‌లతో పని చేస్తున్నప్పుడు ఇంకా చాలా ఆపదలు ఉండవచ్చు మరియు వాటిలో చాలా వాటికి సృజనాత్మక విధానం అవసరం. మీరు సాధనాన్ని సరిగ్గా ఉపయోగిస్తే, ఈ ఆపదలను చాలా వరకు నివారించవచ్చని అర్థం చేసుకోవడం ముఖ్యం. ప్రత్యేకంగా, నేను వివిధ రూపాల్లో జాబితా చేయబడిన అన్ని సమస్యలను ఎదుర్కోవలసి వచ్చింది మరియు వాటిలో కొన్ని నా తప్పుల ఫలితంగా ఉన్నాయి. ఎక్కువగా ఇది అజాగ్రత్త కారణంగా జరుగుతుంది, కానీ కొన్నిసార్లు సాధనాన్ని ఉపయోగించడంలో నేరపూరిత అసమర్థత కారణంగా.
మూలం: www.habr.com