ಹಿಂದೆಂದೂ ಸಂಭವಿಸಿಲ್ಲ, ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಮತ್ತೆ ಹೋಗುತ್ತೇವೆ!
ನಮ್ಮ ಮುಂದಿನ ಯೋಜನೆಯಲ್ಲಿ, ಭವಿಷ್ಯದಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಮೊದಲಿನಿಂದಲೂ ಲಿಕ್ವಿಬೇಸ್ ಅನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಅದು ಬದಲಾದಂತೆ, ಎಲ್ಲಾ ಯುವ ತಂಡದ ಸದಸ್ಯರಿಗೆ ಅದನ್ನು ಸರಿಯಾಗಿ ಬಳಸುವುದು ಹೇಗೆ ಎಂದು ತಿಳಿದಿಲ್ಲ. ನಾನು ಆಂತರಿಕ ಕಾರ್ಯಾಗಾರವನ್ನು ನಡೆಸಿದೆ, ನಂತರ ನಾನು ಅದನ್ನು ಲೇಖನವನ್ನಾಗಿ ಮಾಡಲು ನಿರ್ಧರಿಸಿದೆ.
ಲೇಖನವು ಉಪಯುಕ್ತ ಸಲಹೆಗಳನ್ನು ಮತ್ತು ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್ ವಲಸೆ ಪರಿಕರಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ನೀವು ಬೀಳಬಹುದಾದ ಮೂರು ಸ್ಪಷ್ಟವಾದ ಮೋಸಗಳ ವಿವರಣೆಯನ್ನು ಒಳಗೊಂಡಿದೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ ಲಿಕ್ವಿಬೇಸ್. ಜಾವಾ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಜೂನಿಯರ್ ಮತ್ತು ಮಿಡಲ್ ಹಂತಗಳಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ; ಹೆಚ್ಚು ಅನುಭವಿ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದು ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ರಚನೆ ಮತ್ತು ಪುನರಾವರ್ತನೆಗೆ ಆಸಕ್ತಿಯಿರಬಹುದು.
ಲಿಕ್ವಿಬೇಸ್ ಮತ್ತು ಫ್ಲೈವೇ ಜಾವಾ ಜಗತ್ತಿನಲ್ಲಿ ಸಂಬಂಧಿತ ರಚನೆಗಳ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮುಖ್ಯ ಸ್ಪರ್ಧಾತ್ಮಕ ತಂತ್ರಜ್ಞಾನಗಳಾಗಿವೆ. ಮೊದಲನೆಯದು ಸಂಪೂರ್ಣವಾಗಿ ಉಚಿತವಾಗಿದೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಕೆಗಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ, ಅದಕ್ಕಾಗಿಯೇ ಲಿಕ್ವಿಬೇಸ್ ಅನ್ನು ಪ್ರಕಟಣೆಯ ನಾಯಕನಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ವಿವರಿಸಲಾದ ಕೆಲವು ಅಭ್ಯಾಸಗಳು ಸಾರ್ವತ್ರಿಕವಾಗಿರಬಹುದು.
ಸಂಬಂಧಿತ ರಚನೆಗಳ ವಲಸೆಗಳು ಸಂಬಂಧಿತ ಡೇಟಾ ಸ್ಟೋರ್‌ಗಳ ದುರ್ಬಲ ನಮ್ಯತೆಯನ್ನು ಎದುರಿಸಲು ಬಲವಂತದ ಮಾರ್ಗವಾಗಿದೆ. OOP ಫ್ಯಾಶನ್ ಯುಗದಲ್ಲಿ, ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಶೈಲಿಯು ನಾವು ಸ್ಕೀಮಾವನ್ನು ಒಮ್ಮೆ ವಿವರಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ ಎಂದರ್ಥ. ಆದರೆ ವಾಸ್ತವವೆಂದರೆ ಯಾವಾಗಲೂ ವಿಷಯಗಳು ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಟೇಬಲ್ ರಚನೆಯಲ್ಲಿ ಬದಲಾವಣೆಗಳು ಆಗಾಗ್ಗೆ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಪ್ರಕ್ರಿಯೆಯು ನೋವಿನಿಂದ ಕೂಡಿದೆ ಮತ್ತು ಅಹಿತಕರವಾಗಿರುತ್ತದೆ.
ನಿಮ್ಮ ಯೋಜನೆಗೆ ಲೈಬ್ರರಿಯನ್ನು ಸೇರಿಸುವ ತಂತ್ರಜ್ಞಾನ ಮತ್ತು ಸೂಚನೆಗಳ ವಿವರಣೆಗೆ ನಾನು ಆಳವಾಗಿ ಹೋಗುವುದಿಲ್ಲ; ಈ ವಿಷಯದ ಕುರಿತು ಕೆಲವು ಲೇಖನಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ:
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಉಪಯುಕ್ತ ಸಲಹೆಗಳ ವಿಷಯದ ಕುರಿತು ಈಗಾಗಲೇ ಅತ್ಯುತ್ತಮ ಲೇಖನವಿದೆ:
ಸಲಹೆಗಳು
ವಲಸೆಯೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಬೆವರು, ರಕ್ತ ಮತ್ತು ನೋವಿನ ಮೂಲಕ ಹುಟ್ಟಿದ ನನ್ನ ಸಲಹೆ ಮತ್ತು ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
1. ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನೀವು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳ ವಿಭಾಗದೊಂದಿಗೆ ನೀವೇ ಪರಿಚಿತರಾಗಿರಬೇಕು ಲಿಕ್ವಿಬೇಸ್
ಸರಳವಾದ ಆದರೆ ಬಹಳ ಮುಖ್ಯವಾದ ವಿಷಯಗಳನ್ನು ವಿವರಿಸಲಾಗಿದೆ, ಅದು ಇಲ್ಲದೆ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುವುದರಿಂದ ನಿಮ್ಮ ಜೀವನವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಬದಲಾವಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ರಚನೆಯಿಲ್ಲದ ವಿಧಾನವು ಬೇಗ ಅಥವಾ ನಂತರ ಗೊಂದಲ ಮತ್ತು ಮುರಿದ ವಲಸೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನೀವು ಅದೇ ಸಮಯದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ರಚನೆ ಮತ್ತು ಸೇವಾ ತರ್ಕಕ್ಕೆ ಪರಸ್ಪರ ಅವಲಂಬಿತ ಬದಲಾವಣೆಗಳನ್ನು ರೋಲ್ ಮಾಡದಿದ್ದರೆ, ಇದು ಕೆಂಪು ಪರೀಕ್ಷೆಗಳು ಅಥವಾ ಮುರಿದ ವಾತಾವರಣಕ್ಕೆ ಕಾರಣವಾಗುವ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅಧಿಕೃತ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಲಿಕ್ವಿಬೇಸ್ ಅನ್ನು ಬಳಸುವ ಶಿಫಾರಸುಗಳು ಮುಖ್ಯ ವಲಸೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಜೊತೆಗೆ ರೋಲ್‌ಬ್ಯಾಕ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ಷರತ್ತುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಸರಿ, ಲೇಖನದಲ್ಲಿ ವಲಸೆಗಳು ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಕೋಡ್ ಉದಾಹರಣೆಗಳಿವೆ.
2. ನೀವು ವಲಸೆ ಪರಿಕರಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಡೇಟಾಬೇಸ್ ರಚನೆಯಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ತಿದ್ದುಪಡಿಗಳನ್ನು ಅನುಮತಿಸಬೇಡಿ
ಗಾದೆ ಹೇಳುವಂತೆ: "ಒಮ್ಮೆ ಪರ್ಸಿಲ್, ಯಾವಾಗಲೂ ಪರ್ಸಿಲ್." ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೂಲವನ್ನು Liquibase ನಿಂದ ನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಯಾವುದೇ ಹಸ್ತಚಾಲಿತ ಬದಲಾವಣೆಗಳು ತಕ್ಷಣವೇ ಅಸಮಂಜಸ ಸ್ಥಿತಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ ಮತ್ತು ಬದಲಾವಣೆಗಳ ಮೇಲಿನ ನಂಬಿಕೆಯ ಮಟ್ಟವು ಶೂನ್ಯವಾಗುತ್ತದೆ. ಸಂಭಾವ್ಯ ಅಪಾಯಗಳು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಖರ್ಚು ಮಾಡುತ್ತವೆ; ಕೆಟ್ಟ ಸನ್ನಿವೇಶದಲ್ಲಿ, ಡೆಡ್ ಸರ್ವರ್. ನಿಮ್ಮ ತಂಡದಲ್ಲಿ "ಹಳೆಯ ಶಾಲೆ" DBA ಆರ್ಕಿಟೆಕ್ಟ್ ಇದ್ದರೆ, ಷರತ್ತುಬದ್ಧ SQL ಡೆವಲಪರ್‌ನಿಂದ ತನ್ನ ಸ್ವಂತ ತಿಳುವಳಿಕೆಗೆ ಅನುಗುಣವಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸರಳವಾಗಿ ಸಂಪಾದಿಸಿದರೆ ಅದು ಎಷ್ಟು ಕೆಟ್ಟದು ಎಂದು ತಾಳ್ಮೆಯಿಂದ ಮತ್ತು ಚಿಂತನಶೀಲವಾಗಿ ಅವನಿಗೆ ವಿವರಿಸಿ.
3. ಬದಲಾವಣೆಗಳನ್ನು ಈಗಾಗಲೇ ರೆಪೊಸಿಟರಿಗೆ ತಳ್ಳಿದ್ದರೆ, ಸಂಪಾದನೆಯನ್ನು ತಪ್ಪಿಸಿ
ಇನ್ನೊಬ್ಬ ಡೆವಲಪರ್ ಪುಲ್ ಮಾಡಿದರೆ ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಿದರೆ, ಅದನ್ನು ನಂತರ ಸಂಪಾದಿಸಲಾಗುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ಅವರು ದೋಷವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಅವರು ಖಂಡಿತವಾಗಿಯೂ ಒಂದು ರೀತಿಯ ಪದದೊಂದಿಗೆ ನಿಮ್ಮನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಬದಲಾವಣೆಗಳ ಸಂಪಾದನೆಯು ಹೇಗಾದರೂ ಅಭಿವೃದ್ಧಿಗೆ ಸೋರಿಕೆಯಾದರೆ, ನೀವು ಹಾಟ್‌ಫಿಕ್ಸ್‌ಗಳ ಜಾರು ಇಳಿಜಾರನ್ನು ಅನುಸರಿಸಬೇಕಾಗುತ್ತದೆ. ಸಮಸ್ಯೆಯ ಮೂಲತತ್ವವು ಹ್ಯಾಶ್ ಮೊತ್ತದಿಂದ ಬದಲಾವಣೆಗಳ ಮೌಲ್ಯೀಕರಣದ ಮೇಲೆ ನಿಂತಿದೆ - ಲಿಕ್ವಿಬೇಸ್‌ನ ಮುಖ್ಯ ಕಾರ್ಯವಿಧಾನ. ಬದಲಾವಣೆ ಕೋಡ್ ಅನ್ನು ಸಂಪಾದಿಸುವಾಗ, ಹ್ಯಾಶ್ ಮೊತ್ತವು ಬದಲಾಗುತ್ತದೆ. ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮೊದಲಿನಿಂದ ನಿಯೋಜಿಸಲು ಸಾಧ್ಯವಾದಾಗ ಮಾತ್ರ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಪಾದಿಸುವುದು ಸಾಧ್ಯ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, SQL ಅಥವಾ XML ಕೋಡ್ ಅನ್ನು ಮರುಫಲಕ ಮಾಡುವುದರಿಂದ, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ವಲಸೆಗಳನ್ನು ಹೆಚ್ಚು ಓದಬಹುದಾಗಿದೆ. ಒಂದು ಉದಾಹರಣೆಯೆಂದರೆ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರಾರಂಭದಲ್ಲಿ, ಮೂಲ ಡೇಟಾಬೇಸ್‌ನ ಸ್ಕೀಮಾವನ್ನು ತಂಡದೊಳಗೆ ಒಪ್ಪಿಕೊಳ್ಳಲಾಗಿದೆ.
4. ಸಾಧ್ಯವಾದರೆ ಪರಿಶೀಲಿಸಿದ ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಹೊಂದಿರಿ
ಇಲ್ಲಿ, ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ವಲಸೆ ವಿಫಲವಾದರೆ, ಎಲ್ಲವನ್ನೂ ಹಿಂತಿರುಗಿಸಬಹುದು. ಲಿಕ್ವಿಬೇಸ್ ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲು ಒಂದು ಸಾಧನವನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ರೋಲ್‌ಬ್ಯಾಕ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಡೆವಲಪರ್ ಸ್ವತಃ ಬರೆದಿದ್ದಾರೆ ಮತ್ತು ಮುಖ್ಯ ಬದಲಾವಣೆಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಂತೆಯೇ ಅದೇ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಅವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳೊಂದಿಗೆ ಸುರಕ್ಷಿತವಾಗಿ ಪ್ಲೇ ಮಾಡಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದರ್ಥ.
5. ಸಾಧ್ಯವಾದರೆ, ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸಾಬೀತಾಗಿರುವ ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಬಳಸಿ
ಇದು ಒಪ್ಪಂದಗಳು ಮತ್ತು ಗೌಪ್ಯತೆಗೆ ವಿರುದ್ಧವಾಗಿಲ್ಲದಿದ್ದರೆ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಯಾವುದೇ ವೈಯಕ್ತಿಕ ಡೇಟಾ ಇಲ್ಲ, ಮತ್ತು ಅದು ಎರಡು ಸೂರ್ಯಗಳಿಗಿಂತ ಹೆಚ್ಚು ತೂಕವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ - ಲೈವ್ ಮೈಗ್ರೇಷನ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ಬಳಸುವ ಮೊದಲು, ಡೆವಲಪರ್‌ನ ಯಂತ್ರದಲ್ಲಿ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು ವಲಸೆಯ ಸಮಯದಲ್ಲಿ ಸುಮಾರು 100% ಸಂಭಾವ್ಯ ಸಮಸ್ಯೆಗಳು.
6. ತಂಡದ ಇತರ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಿ
ಸುಸಂಘಟಿತ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಯಾರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ತಂಡದ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ತಿಳಿದಿದೆ. ವಾಸ್ತವದಲ್ಲಿ, ಇದು ಆಗಾಗ್ಗೆ ಅಲ್ಲ, ಆದ್ದರಿಂದ, ನಿಮ್ಮ ಕಾರ್ಯದ ಭಾಗವಾಗಿ ನೀವು ಡೇಟಾಬೇಸ್ ರಚನೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತಿದ್ದರೆ, ಇದರ ಬಗ್ಗೆ ಸಂಪೂರ್ಣ ತಂಡಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ ತಿಳಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ. ಯಾರಾದರೂ ಸಮಾನಾಂತರವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದರೆ, ನೀವು ಎಚ್ಚರಿಕೆಯಿಂದ ಸಂಘಟಿಸಬೇಕು. ಪ್ರಾರಂಭದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಕೆಲಸವನ್ನು ಮುಗಿಸಿದ ನಂತರ ಸಹೋದ್ಯೋಗಿಗಳೊಂದಿಗೆ ಸಂವಹನ ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಬದಲಾವಣೆಗಳೊಂದಿಗಿನ ಅನೇಕ ಸಂಭಾವ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಕೋಡ್ ವಿಮರ್ಶೆ ಹಂತದಲ್ಲಿ ಪರಿಹರಿಸಬಹುದು.
7. ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಯೋಚಿಸಿ!
ಇದು ಯಾವುದೇ ಪರಿಸ್ಥಿತಿಗೆ ಅನ್ವಯಿಸುವ ಸ್ವಯಂ-ಸ್ಪಷ್ಟ ಸಲಹೆಯಂತೆ ತೋರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಡೆವಲಪರ್ ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಅದು ಏನು ಪರಿಣಾಮ ಬೀರಬಹುದು ಎಂಬುದನ್ನು ಮತ್ತೊಮ್ಮೆ ವಿಶ್ಲೇಷಿಸಿದ್ದರೆ ಅನೇಕ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು. ವಲಸೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಯಾವಾಗಲೂ ಹೆಚ್ಚುವರಿ ಗಮನ ಮತ್ತು ನಿಖರತೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಬಲೆಗಳು
ಮೇಲಿನ ಸಲಹೆಯನ್ನು ನೀವು ಅನುಸರಿಸದಿದ್ದರೆ ನೀವು ಬೀಳಬಹುದಾದ ವಿಶಿಷ್ಟ ಬಲೆಗಳನ್ನು ಈಗ ನೋಡೋಣ ಮತ್ತು ನಿಖರವಾಗಿ ನೀವು ಏನು ಮಾಡಬೇಕು?
ಪರಿಸ್ಥಿತಿ 1: ಇಬ್ಬರು ಡೆವಲಪರ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ
ವಾಸ್ಯಾ ಮತ್ತು ಪೆಟ್ಯಾ ಪರಸ್ಪರರ ಬಗ್ಗೆ ತಿಳಿಯದೆ ಬದಲಾವಣೆಯ ಆವೃತ್ತಿ 4 ಅನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತಾರೆ. ಅವರು ಡೇಟಾಬೇಸ್ ರಚನೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದರು ಮತ್ತು ವಿವಿಧ ಬದಲಾವಣೆಗಳ ಫೈಲ್ಗಳೊಂದಿಗೆ ಪುಲ್ ವಿನಂತಿಯನ್ನು ನೀಡಿದರು. ಕೆಳಗಿನ ಕ್ರಿಯೆಯ ಕಾರ್ಯವಿಧಾನವನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ:
ಹೇಗೆ ಪರಿಹರಿಸುವುದು
- ಹೇಗಾದರೂ, ಸಹೋದ್ಯೋಗಿಗಳು ತಮ್ಮ ಬದಲಾವಣೆಗಳು ಯಾವ ಕ್ರಮದಲ್ಲಿ ಹೋಗಬೇಕು ಎಂಬುದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು, ಉದಾಹರಣೆಗೆ, ಪೆಟಿನ್ ಅನ್ನು ಮೊದಲು ಅನ್ವಯಿಸಬೇಕು.
- ಯಾರಾದರೂ ಎರಡನೆಯದನ್ನು ತಮ್ಮೊಂದಿಗೆ ಸೇರಿಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ವಾಸ್ಯಾ ಅವರ ಬದಲಾವಣೆಯನ್ನು ಆವೃತ್ತಿ 5 ರೊಂದಿಗೆ ಗುರುತಿಸಬೇಕು. ಇದನ್ನು ಚೆರ್ರಿ ಪಿಕ್ ಅಥವಾ ಅಚ್ಚುಕಟ್ಟಾಗಿ ವಿಲೀನಗೊಳಿಸಬಹುದು.
- ಬದಲಾವಣೆಗಳ ನಂತರ, ತೆಗೆದುಕೊಂಡ ಕ್ರಮಗಳ ಸಿಂಧುತ್ವವನ್ನು ನೀವು ಖಂಡಿತವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕು.
ವಾಸ್ತವವಾಗಿ, ಲಿಕ್ವಿಬೇಸ್ ಕಾರ್ಯವಿಧಾನಗಳು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಎರಡು ಆವೃತ್ತಿ 4 ಬದಲಾವಣೆಗಳನ್ನು ಹೊಂದಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಎಲ್ಲವನ್ನೂ ಹಾಗೆಯೇ ಬಿಡಬಹುದು. ಅಂದರೆ, ನೀವು ವಿಭಿನ್ನ ಹೆಸರುಗಳೊಂದಿಗೆ ಆವೃತ್ತಿ 4 ಗೆ ಎರಡು ಬದಲಾವಣೆಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಈ ವಿಧಾನದೊಂದಿಗೆ, ನಂತರ ಡೇಟಾಬೇಸ್ ಆವೃತ್ತಿಗಳನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು ತುಂಬಾ ಕಷ್ಟವಾಗುತ್ತದೆ.
ಇದರ ಜೊತೆಗೆ, ಲಿಕ್ವಿಬೇಸ್, ಹಾಬಿಟ್‌ಗಳ ಮನೆಯಂತೆ, ಅನೇಕ ರಹಸ್ಯಗಳನ್ನು ಇಡುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ವ್ಯಾಲಿಡ್‌ಚೆಕ್‌ಸಮ್ ಕೀ, ಇದು ಆವೃತ್ತಿ 1.7 ರಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಏನನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂಬುದರ ಹೊರತಾಗಿಯೂ, ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಗೆ ಮಾನ್ಯವಾದ ಹ್ಯಾಶ್ ಮೌಲ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ದಾಖಲೆ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಹೇಳುತ್ತದೆ:
ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಏನನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂಬುದರ ಹೊರತಾಗಿಯೂ, ಈ ಬದಲಾವಣೆ ಸೆಟ್‌ಗೆ ಮಾನ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾದ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಸೇರಿಸಿ. ನೀವು ಬದಲಾವಣೆ ಸೆಟ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕಾದಾಗ ಪ್ರಾಥಮಿಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಈಗಾಗಲೇ ರನ್ ಆಗಿರುವ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಎಸೆಯಲು ಬಯಸುವುದಿಲ್ಲ (ಶಿಫಾರಸು ಮಾಡಿದ ಕಾರ್ಯವಿಧಾನವಲ್ಲ)
ಹೌದು, ಹೌದು, ಈ ವಿಧಾನವನ್ನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ. ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಬಲವಾದ ಬೆಳಕಿನ ಜಾದೂಗಾರನು ಡಾರ್ಕ್ ತಂತ್ರಗಳನ್ನು ಸಹ ಕರಗತ ಮಾಡಿಕೊಳ್ಳುತ್ತಾನೆ
ಸನ್ನಿವೇಶ 2: ಡೇಟಾದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ವಲಸೆ
ಲೈವ್ ಸರ್ವರ್‌ಗಳಿಂದ ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀವು ಹೊಂದಿಲ್ಲ ಎಂದು ಭಾವಿಸೋಣ. ಪೆಟ್ಯಾ ಅವರು ಬದಲಾವಣೆಯನ್ನು ರಚಿಸಿದರು, ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಪರೀಕ್ಷಿಸಿದರು ಮತ್ತು ಅವರು ಸರಿ ಎಂದು ಸಂಪೂರ್ಣ ವಿಶ್ವಾಸದಿಂದ ಡೆವಲಪರ್‌ಗೆ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮಾಡಿದರು. ಒಂದು ವೇಳೆ, ಪೆಟ್ಯಾ ಅದನ್ನು ಪರಿಶೀಲಿಸಿದೆಯೇ ಎಂದು ಪ್ರಾಜೆಕ್ಟ್ ಲೀಡ್ ಸ್ಪಷ್ಟಪಡಿಸಿದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಸೇರಿಸಿದೆ. ಆದರೆ ಅಭಿವೃದ್ಧಿ ಸರ್ವರ್‌ನಲ್ಲಿ ನಿಯೋಜನೆ ಕುಸಿಯಿತು.
ವಾಸ್ತವವಾಗಿ, ಇದು ಸಾಧ್ಯ, ಮತ್ತು ಯಾರೂ ಇದರಿಂದ ವಿನಾಯಿತಿ ಹೊಂದಿಲ್ಲ. ಟೇಬಲ್ ರಚನೆಗೆ ಮಾರ್ಪಾಡುಗಳನ್ನು ಹೇಗಾದರೂ ಡೇಟಾಬೇಸ್ನಿಂದ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಗೆ ಜೋಡಿಸಿದರೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಪೆಟ್ಯಾ ಅವರ ಡೇಟಾಬೇಸ್ ಪರೀಕ್ಷಾ ಡೇಟಾದಿಂದ ಮಾತ್ರ ತುಂಬಿದ್ದರೆ, ಅದು ಎಲ್ಲಾ ಸಮಸ್ಯೆ ಪ್ರಕರಣಗಳನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಟೇಬಲ್ ಅನ್ನು ಅಳಿಸುವಾಗ, ವಿದೇಶಿ ಕೀಲಿಯಿಂದ ಇತರ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ದಾಖಲೆಗಳಿವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಅದು ಅಳಿಸಲಾದ ದಾಖಲೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಅಥವಾ ಕಾಲಮ್ ಪ್ರಕಾರವನ್ನು ಬದಲಾಯಿಸುವಾಗ, 100% ಡೇಟಾವನ್ನು ಹೊಸ ಪ್ರಕಾರಕ್ಕೆ ಪರಿವರ್ತಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ಹೇಗೆ ಪರಿಹರಿಸುವುದು
- ವಲಸೆಯ ಜೊತೆಗೆ ಒಮ್ಮೆ ಬಳಸಲಾಗುವ ವಿಶೇಷ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ಡೇಟಾವನ್ನು ಸರಿಯಾದ ರೂಪಕ್ಕೆ ತರಲು. ವಲಸೆಯನ್ನು ಅನ್ವಯಿಸಿದ ನಂತರ ಹೊಸ ರಚನೆಗಳಿಗೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಇದು ಸಾಮಾನ್ಯ ಮಾರ್ಗವಾಗಿದೆ, ಆದರೆ ವಿಶೇಷ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದೇ ರೀತಿಯದನ್ನು ಮೊದಲು ಅನ್ವಯಿಸಬಹುದು. ಈ ಮಾರ್ಗವು ಯಾವಾಗಲೂ ಲಭ್ಯವಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಲೈವ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಪಾದಿಸುವುದು ಅಪಾಯಕಾರಿ ಮತ್ತು ವಿನಾಶಕಾರಿಯಾಗಿದೆ.
- ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಪಾದಿಸುವುದು ಮತ್ತೊಂದು ಕಷ್ಟಕರವಾದ ಮಾರ್ಗವಾಗಿದೆ. ತೊಂದರೆ ಏನೆಂದರೆ, ಅದರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ರೂಪದಲ್ಲಿ ಈಗಾಗಲೇ ಅನ್ವಯಿಸಲಾದ ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ. ಸಂಪೂರ್ಣ ಬ್ಯಾಕೆಂಡ್ ತಂಡವು ಮೊದಲಿನಿಂದಲೂ ಸ್ಥಳೀಯವಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊರತರುವಂತೆ ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ.
- ಮತ್ತು ಅತ್ಯಂತ ಸಾರ್ವತ್ರಿಕ ಮಾರ್ಗವೆಂದರೆ ಡೆವಲಪರ್‌ನ ಪರಿಸರಕ್ಕೆ ಡೇಟಾದೊಂದಿಗಿನ ಸಮಸ್ಯೆಯನ್ನು ವರ್ಗಾಯಿಸುವುದು, ಅದೇ ಪರಿಸ್ಥಿತಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು ಮತ್ತು ಮುರಿದ ಒಂದಕ್ಕೆ ಹೊಸ ಬದಲಾವಣೆಯನ್ನು ಸೇರಿಸುವುದು, ಅದು ಸಮಸ್ಯೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಯೋಜನೆಯಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಹೆಚ್ಚು ಹೋಲುತ್ತದೆ, ವಲಸೆಯೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳು ದೂರ ಹೋಗುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ನೀವು ರೆಪೊಸಿಟರಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು, ಅದು ಏನನ್ನಾದರೂ ಮುರಿಯುತ್ತದೆಯೇ ಎಂದು ನೀವು ಹಲವಾರು ಬಾರಿ ಯೋಚಿಸಬೇಕು.
ಪರಿಸ್ಥಿತಿ 3. ಲಿಕ್ವಿಬೇಸ್ ಉತ್ಪಾದನೆಗೆ ಹೋದ ನಂತರ ಅದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ
ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಲಿಕ್ವಿಬೇಸ್ ಅನ್ನು ಸೇರಿಸಲು ತಂಡದ ಪ್ರಮುಖರು ಪೆಟ್ಯಾ ಅವರನ್ನು ಕೇಳಿದ್ದಾರೆ ಎಂದು ಭಾವಿಸೋಣ, ಆದರೆ ಯೋಜನೆಯು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿದೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾಬೇಸ್ ರಚನೆ ಇದೆ.
ಅಂತೆಯೇ, ಸಮಸ್ಯೆಯೆಂದರೆ ಯಾವುದೇ ಹೊಸ ಸರ್ವರ್‌ಗಳು ಅಥವಾ ಡೆವಲಪರ್ ಯಂತ್ರಗಳಲ್ಲಿ, ಈ ಕೋಷ್ಟಕಗಳನ್ನು ಮೊದಲಿನಿಂದ ಮರುಸೃಷ್ಟಿಸಬೇಕು ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಸರವು ಸ್ಥಿರ ಸ್ಥಿತಿಯಲ್ಲಿ ಉಳಿಯಬೇಕು, ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿದೆ.
ಹೇಗೆ ಪರಿಹರಿಸುವುದು
ಹಲವಾರು ಮಾರ್ಗಗಳಿವೆ:
- ಹೊಸ ಪರಿಸರವನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ಹಸ್ತಚಾಲಿತವಾಗಿ ಅನ್ವಯಿಸಬೇಕಾದ ಪ್ರತ್ಯೇಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಹೊಂದಿರುವುದು ಮೊದಲ ಮತ್ತು ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾಗಿದೆ.
- ಎರಡನೆಯದು ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಮತ್ತೊಂದು ಲಿಕ್ವಿಬೇಸ್ ಸನ್ನಿವೇಶದಲ್ಲಿರುವ ಲಿಕ್ವಿಬೇಸ್ ವಲಸೆಯನ್ನು ಹೊಂದಿರಿ ಮತ್ತು ಅದನ್ನು ಅನ್ವಯಿಸಿ. Liquibase ಸಂದರ್ಭದ ಕುರಿತು ನೀವು ಇಲ್ಲಿ ಇನ್ನಷ್ಟು ಓದಬಹುದು: . ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸಬಹುದಾದ ಆಸಕ್ತಿದಾಯಕ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಪರೀಕ್ಷೆಗಾಗಿ.
- ಮೂರನೇ ಮಾರ್ಗವು ಹಲವಾರು ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮೊದಲಿಗೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಷ್ಟಕಗಳಿಗೆ ವಲಸೆಯನ್ನು ರಚಿಸಬೇಕು. ನಂತರ ಅದನ್ನು ಕೆಲವು ಪರಿಸರಕ್ಕೆ ಅನ್ವಯಿಸಬೇಕು ಮತ್ತು ಹೀಗಾಗಿ ಅದರ ಹ್ಯಾಶ್ ಮೊತ್ತವನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ. ಮುಂದಿನ ಹಂತವು ನಮ್ಮ ಖಾಲಿ ಅಲ್ಲದ ಸರ್ವರ್‌ನಲ್ಲಿ ಖಾಲಿ ಲಿಕ್ವಿಬೇಸ್ ಕೋಷ್ಟಕಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಮತ್ತು ಬದಲಾವಣೆಗಳ ಬಳಕೆಯ ಇತಿಹಾಸದೊಂದಿಗೆ ಟೇಬಲ್‌ನಲ್ಲಿ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ “ಅನ್ವಯಿಸಿದಂತೆ” ಬದಲಾವಣೆಗಳ ಕುರಿತು ನೀವು ಹಸ್ತಚಾಲಿತವಾಗಿ ದಾಖಲೆಯನ್ನು ಹಾಕಬಹುದು. . ಹೀಗಾಗಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸರ್ವರ್‌ನಲ್ಲಿ, ಇತಿಹಾಸದ ಕೌಂಟ್‌ಡೌನ್ ಆವೃತ್ತಿ 2 ರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಹೊಸ ಪರಿಸರಗಳು ಒಂದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ.
ಪರಿಸ್ಥಿತಿ 4. ವಲಸೆಗಳು ದೊಡ್ಡದಾಗುತ್ತವೆ ಮತ್ತು ಪೂರ್ಣಗೊಳ್ಳಲು ಸಮಯವಿಲ್ಲ
ಸೇವೆಯ ಅಭಿವೃದ್ಧಿಯ ಆರಂಭದಲ್ಲಿ, ನಿಯಮದಂತೆ, ಲಿಕ್ವಿಬೇಸ್ ಅನ್ನು ಬಾಹ್ಯ ಅವಲಂಬನೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವಾದಾಗ ಎಲ್ಲಾ ವಲಸೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಕಾಲಾನಂತರದಲ್ಲಿ, ನೀವು ಈ ಕೆಳಗಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಎಡವಬಹುದು:
- ವಲಸೆಗಳು ದೊಡ್ಡದಾಗುತ್ತವೆ ಮತ್ತು ಪೂರ್ಣಗೊಳ್ಳಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
- ವಿತರಿಸಿದ ಪರಿಸರದಲ್ಲಿ ವಲಸೆಯ ಅವಶ್ಯಕತೆಯಿದೆ, ಉದಾಹರಣೆಗೆ, ಹಲವಾರು ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ನಿದರ್ಶನಗಳಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬಹಳ ಸಮಯದವರೆಗೆ ವಲಸೆಗಳನ್ನು ಅನ್ವಯಿಸುವುದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ಸಮಯ ಮೀರುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ನಿದರ್ಶನಕ್ಕೆ ವಲಸೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಅನ್ವಯಿಸುವುದರಿಂದ ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳು ಸಿಂಕ್ ಆಗುವುದಿಲ್ಲ.
ಹೇಗೆ ಪರಿಹರಿಸುವುದು
ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಈಗಾಗಲೇ ದೊಡ್ಡದಾಗಿದೆ, ಬಹುಶಃ ವಯಸ್ಕರೂ ಸಹ, ಮತ್ತು ಲಿಕ್ವಿಬೇಸ್ ಪ್ರತ್ಯೇಕ ಬಾಹ್ಯ ಸಾಧನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಲೈಬ್ರರಿಯಾಗಿ ಲಿಕ್ವಿಬೇಸ್ ಅನ್ನು ಜಾರ್ ಫೈಲ್‌ಗೆ ಸಂಕಲಿಸಲಾಗಿದೆ ಮತ್ತು ಯೋಜನೆಯೊಳಗೆ ಅಥವಾ ಸ್ವತಂತ್ರವಾಗಿ ಅವಲಂಬನೆಯಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು ಎಂಬುದು ಸತ್ಯ.
ಸ್ವತಂತ್ರ ಮೋಡ್‌ನಲ್ಲಿ, ನಿಮ್ಮ CI/CD ಪರಿಸರಕ್ಕೆ ಅಥವಾ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಮತ್ತು ನಿಯೋಜನೆ ತಜ್ಞರ ಬಲವಾದ ಭುಜಗಳಿಗೆ ವಲಸೆಗಳ ಅನುಷ್ಠಾನವನ್ನು ನೀವು ಬಿಡಬಹುದು. ಇದನ್ನು ಮಾಡಲು ನಿಮಗೆ Liquibase ಆಜ್ಞಾ ಸಾಲಿನ ಅಗತ್ಯವಿದೆ . ಈ ಕ್ರಮದಲ್ಲಿ, ಎಲ್ಲಾ ಅಗತ್ಯ ವಲಸೆಗಳನ್ನು ನಡೆಸಿದ ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ತೀರ್ಮಾನಕ್ಕೆ
ವಾಸ್ತವವಾಗಿ, ಡೇಟಾಬೇಸ್ ವಲಸೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಹೆಚ್ಚಿನ ಮೋಸಗಳು ಇರಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹಲವು ಸೃಜನಾತ್ಮಕ ವಿಧಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ. ನೀವು ಉಪಕರಣವನ್ನು ಸರಿಯಾಗಿ ಬಳಸಿದರೆ, ಈ ಹೆಚ್ಚಿನ ಮೋಸಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪಟ್ಟಿ ಮಾಡಲಾದ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ನಾನು ವಿವಿಧ ರೂಪಗಳಲ್ಲಿ ಎದುರಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕೆಲವು ನನ್ನ ತಪ್ಪುಗಳ ಪರಿಣಾಮವಾಗಿದೆ. ಹೆಚ್ಚಾಗಿ ಇದು ಅಜಾಗರೂಕತೆಯಿಂದ ಸಂಭವಿಸುತ್ತದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಉಪಕರಣವನ್ನು ಬಳಸಲು ಕ್ರಿಮಿನಲ್ ಅಸಮರ್ಥತೆಯಿಂದಾಗಿ.
ಮೂಲ: www.habr.com