ಒಬ್ಬ ಡೆವಲಪರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಫಂಕ್ಷನ್‌ಗೆ CREATE OR REPLACE FUNCTION ಬಳಸಿ ಒಂದು ಐಚ್ಛಿಕ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ, ಪ್ರೊಡಕ್ಷನ್ PostgreSQL ನಿಯೋಜನೆಯು (deployment) ಕುಸಿದಿತು. ಈ ಬದಲಾವಣೆಯು ಒಂದೇ ಹೆಸರಿನ ಎರಡು ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಉಳಿಸಿತು, ಇದರಿಂದಾಗಿ ಡೇಟಾಬೇಸ್ “function is not unique” ಎಂಬ ಸಂದೇಶವನ್ನು ನೀಡಿತು ಮತ್ತು API 400 ಎರರ್ ಅನ್ನು ನೀಡಿತು. ಈ ಘಟನೆಯು ಕೇವಲ ಕೋಡ್-ಮಟ್ಟದ ಪರಿಶೀಲನೆಗಳು ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ ಮತ್ತು ಒಂದು ಸಣ್ಣ ಮೈಗ್ರೇಷನ್ ತಪ್ಪು ಹೇಗೆ ಲೈವ್ ಸ್ಕೀಮಾವನ್ನು ಮೌನವಾಗಿ ಹಾಳುಮಾಡಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಏನಾಗಿದ್ದು

ತಂಡವು ಒಂದು ಸ್ಟೋರ್ಡ್ ಪ್ರೊಸೀಜರ್‌ಗೆ ಹೆಚ್ಚುವರಿ, ಐಚ್ಛಿಕ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸೇರಿಸಬೇಕಾಗಿತ್ತು. ಅವರು ಹಳೆಯ ವ್ಯಾಖ್ಯಾನವನ್ನು (definition) ಇದು ಅಳಿಸಿ ಹೊಸದನ್ನು ಬರೆಯುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ CREATE OR REPLACE FUNCTION … ಅನ್ನು ಚಲಾಯಿಸಿದರು. ಪೂರ್ಣ ಆರ್ಗ್ಯುಮೆಂಟ್ ಪಟ್ಟಿಯು ನಿಖರವಾಗಿ ಹೊಂದಿಕೆಯಾದಾಗ ಮಾತ್ರ PostgreSQL ಫಂಕ್ಷನ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಸಿಗ್ನೇಚರ್ (signature) ಬದಲಾಯಿಸುವುದು ಮೂಲವನ್ನು ಹಾಗೆಯೇ ಉಳಿಸಿ, ಹೊಸ ಫಂಕ್ಷನ್ ಎಂಟ್ರಿಯನ್ನು ರಚಿಸುತ್ತದೆ.

ಹೊಸ ಆರ್ಗ್ಯುಮೆಂಟ್ ಡಿಫಾಲ್ಟ್ ವ್ಯಾಲ್ಯೂ ಅನ್ನು ಹೊಂದಿದ್ದರಿಂದ, ಹಳೆಯ ಸಂಖ್ಯೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ನೀಡುವ ಕರಲರ್‌ಗಳು (callers) ಎರಡೂ ವ್ಯಾಖ್ಯಾನಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಬಹುದು. PostgreSQL ಯಾವ ಫಂಕ್ಷನ್ ಅನ್ನು ಬಳಸಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗದೆ “function is not unique” ಎಂಬ ಎರರ್ ಅನ್ನು ಎಸೆந்தது, ಇದು API ನಿಂದ 400 ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಹೊರಬಂದಿತು.

ಕೋಡ್ ರೆಪೊಸಿಟರಿಯು ಒಂದೇ ವ್ಯಾಖ್ಯಾನವನ್ನು ತೋರಿಸುತ್ತಿತ್ತು ಮತ್ತು ಸೋರ್ಸ್ ಟ್ರೀ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಕಸ್ಟಮ್ ಸ್ಕ್ರಿಪ್ಟ್ ಯಾವುದೇ ಡ್ಯೂಪ್ಲಿಕೇಟ್‌ಗಳನ್ನು ವರದಿ ಮಾಡಲಿಲ್ಲ. ಈ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಕೇವಲ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಇತ್ತು, ಇದನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಹಳೆಯ ಮೈಗ್ರೇಷನ್ ಫೈಲ್ ಅನ್ನು ಮರು-ಚಲಾಯಿಸಿದಾಗ ಪರಿಚಯಿಸಲಾಯಿತು.

ಮೈಗ್ರೇಷನ್ ಏಕೆ ತಪ್ಪಿಹೋಯಿತು

ಐಚ್ಛಿಕ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸೇರಿಸಿದ ಮೈಗ್ರೇಷನ್ ಕೇವಲ CREATE OR REPLACE FUNCTION ಅನ್ನು ಚಲಾಯಿಸಿತು. ಮೈಗ್ರೇಷನ್ ಎರಡನೇ ಬಾರಿಗೆ ಚಲಾಯಿಸಿದಾಗ—ಬಹುಶಃ ರೋಲ್‌ಬ್ಯಾಕ್ ನಂತರ ಅಥವಾ ಪುನರಾವರ್ತಿತ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ—ಡೇಟಾಬೇಸ್ ಆ ಕಮಾಂಡ್ ಅನ್ನು "ಹೊಸದನ್ನು ಸೇರಿಸು" ಎಂದು ಪರಿಗಣಿಸಿತೇ ಹೊರತು "ಅಸ್ತಿತ್ವದಲ್ಲಿರುವದ್ದನ್ನು ಬದಲಾಯಿಸು" ಎಂದು ಪರಿಗಣಿಸಲಿಲ್ಲ. ಮೈಗ್ರೇಷನ್ ಉಂಟಾದ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಗಮನಕ್ಕೆ ಬಾರದೆ ಉಳಿಯಿತು.

ರೆಪೊಸಿಟರಿಯನ್ನು ಪರಿಶೀಲಿಸಿದ ಸ್ಕ್ರಿಪ್ಟ್ ಸೋರ್ಸ್ ಫೈಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿತ್ತು, ಲೈವ್ ಸ್ಕೀಮಾವನ್ನಲ್ಲ. ಅದು ಮುಂಭಾಗದ ಬಾಗಿಲನ್ನು ನೋಡುತ್ತಿತ್ತು, ಆದರೆ ಬಗ್ ಹಿಂಬಾಗಿಲಿನ ಮೂಲಕ ಪ್ರವೇಶಿಸಿತ್ತು.

ಪರಿಣಾಮಗಳು

ಒಂದೇ ಒಂದು ಅಸ್ಪಷ್ಟ ಫಂಕ್ಷನ್ ಅದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಸೇವೆಯನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಬಹುದು. ಫಂಕ್ಷನ್ ಸಂಖ್ಯೆ ತಪ್ಪಾಗಿದ್ದರೆ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅನ್ನು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡುವುದು ಮತ್ತು ಸ್ಕೀಮಾ ಕ್ಯಾಶ್ ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಲು ಸೂಚಿಸುವುದು ಇದರ ಪರಿಹಾರವಾಗಿತ್ತು.

ಮೈಗ್ರೇಷನ್‌ಗಳನ್ನು ಹೇಗೆ ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು

ತಂಡವು ಮೈಗ್ರೇಷನ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾದ ಪರಿಶೀಲನೆಗಳೊಂದಿಗೆ ಮರುನಿರ್ಮಿಸಿತು, ಅದನ್ನು ಸ್ವಯಂ-ದೃಢೀಕರಣ ಕಾರ್ಯಾಚರಣೆಯನ್ನಾಗಿ ಮಾಡಿತು:

  • ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಪ್ರಾರಂಭಿಸಿ (Start a transaction) ಇದರಿಂದ ಯಾವುದೇ ವೈಫಲ್ಯವು ಇಡೀ ಬದಲಾವಣೆಯನ್ನು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡುತ್ತದೆ.
  • ಹಳೆಯ ಫಂಕ್ಷನ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಡ್ರಾಪ್ ಮಾಡಿ (Drop the old function explicitly) ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುವ ಮೊದಲು, ಇದರಿಂದ ಕೇವಲ ಒಂದು ವ್ಯಾಖ್ಯಾನ ಮಾತ್ರ ಇರುವುದು ಖಚಿತವಾಗುತ್ತದೆ.
  • ಹೊಸ ಫಂಕ್ಷನ್ ಅನ್ನು ರಚಿಸಿ (Create the new function) ಬಯಸಿದ ಸಿಗ್ನೇಚರ್‌ನೊಂದಿಗೆ.
  • pg_catalog ನಲ್ಲಿ ಅನ್ವಯವಾಗುವ ಹೆಸರಿನ ಫಂಕ್ಷನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸಿ (Count the functions) ಮತ್ತು ಸಂಖ್ಯೆಯು ನಿಖರವಾಗಿ ಒಂದೇ ಆಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
  • ಸಂಖ್ಯೆಯು ವ್ಯತ್ಯಾಸವಾಗಿದ್ದರೆ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಅನ್ನು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಿ (Roll back), ಇದರಿಂದ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಉಳಿಯದಂತೆ ತಡೆಯಬಹುದು.
  • ಸ್ಕೀಮಾ ಕ್ಯಾಶ್ ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಲು ಸೂಚಿಸಿ (Notify the schema cache), ಇದರಿಂದ ಮುಂದಿನ ಕ್ವೇರಿಗಳು ಅಪ್‌ಡೇಟ್ ಮಾಡಿದ ವ್ಯಾಖ್ಯಾನವನ್ನು ನೋಡುತ್ತವೆ.

ಕೋಡ್ ಸರಿಯಾಗಿದೆ ಎಂದು ಭಾವಿಸುವ ಬದಲು ಡೇಟಾಬೇಸ್‌ಗೆ “ಯಾವ ಫಂಕ್ಷನ್‌ಗಳು ಇವೆ?” ಎಂದು ಕೇಳುವ ಮೂಲಕ, ಮೈಗ್ರೇಷನ್ ಪುನರಾವರ್ತಿತ ರನ್‌ಗಳು, ಭಾಗಶಃ ನಿಯೋಜನೆಗಳು ಅಥವಾ ಮ್ಯಾನುಯಲ್ ಎಡಿಟ್‌ಗಳ ವಿರುದ್ಧ ವಿಶ್ವಾಸಾರ್ಹವಾಗುತ್ತದೆ.

ವಿರೋಧಾತ್ಮಕ ವಾದ: ಅನುಕೂಲತೆ vs ಸುರಕ್ಷತೆ

CREATE OR REPLACE FUNCTION ಆಕರ್ಷಕವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಡೆವಲಪರ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಡ್ರಾಪ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು ಬರೆಯದೆ ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಮೈಗ್ರೇಷನ್‌ಗಳು ಒಮ್ಮೆ ಮಾತ್ರ ಚಲಾಯಿಸಲ್ಪಡುವ ಮತ್ತು ಎಂದಿಗೂ ಮರು-ಚಲಾಯಿಸಲ್ಪಡದ ಪರಿಸರಗಳಲ್ಲಿ, ಈ ಶಾರ್ಟ್‌ಕಟ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮೈಗ್ರೇಷನ್‌ಗಳನ್ನು ಮರು-ಚಲಾಯಿಸಿದಾಗ ಅಪಾಯ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ—ಅದು ಟೆಸ್ಟ್ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ರಿಸೆಟ್ ಮಾಡುವ CI ಪೈಪ್‌ಲೈನ್‌ಗಳಿಂದ, ಸ್ವಯಂಚಾಲಿತ ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳಿಂದ ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಮ್ಯಾನುಯಲ್ ಮರು-ಅನ್ವಯಗಳಿಂದ ಇರಬಹುದು.

ಸಾರಾಂಶ

CREATE OR REPLACE ಬಳಸಿ ಫಂಕ್ಷನ್‌ನ ಸಿಗ್ನೇಚರ್ ಬದಲಾಯಿಸುವುದು ಬದಲಾವಣೆಯನ್ನು ಖಚಿತಪಡಿಸುವುದಿಲ್ಲ—ಆರ್ಗ್ಯುಮೆಂಟ್ ಪಟ್ಟಿಯು ಭಿನ್ನವಾಗಿದ್ದರೆ PostgreSQL ಮೌನವಾಗಿ ಓವರ್‌ಲೋಡ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಮೈಗ್ರೇಷನ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಪ್ರೊಡಕ್ಷನ್ ಪರಿಸರಗಳು ಕೇವಲ ಸೋರ್ಸ್ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಉಂಟಾದ ಸ್ಕೀಮಾವನ್ನು ಸಹ ಪರಿಶೀಲಿಸಬೇಕು. ಸ್ಪಷ್ಟವಾದ ಡ್ರಾಪ್‌ಗಳು, ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಮೈಗ್ರೇಷನ್ ನಂತರದ ದೃಢೀಕರಣಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಅನುಕೂಲಕರ ಶಾರ್ಟ್‌ಕಟ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಪ್ರಕ್ರಿಯೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.