PrestaShop ನ ಗ್ಲೋಬಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಟೇಬಲ್ (global configuration table), ಒಂದು ಮಾಡ್ಯೂಲ್ನ ಅನ್ಇನ್ಸ್ಟಾಲ್ ರೂಟೀನ್ (uninstall routine) ಸಂಪೂರ್ಣವಾಗಿ ಸಂಬಂಧವಿಲ್ಲದ ಇತರ ಎಕ್ಸ್ಟೆನ್ಶನ್ಗಳಿಗೆ ಸೇರಿದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಅಳಿಸಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ. ಕೇವಲ ಒಂದು Configuration::deleteByName('width') ಕರೆ ಮತ್ತೊಂದು ಶಾಪ್ನ ಕಸ್ಟಮ್ 'width' ಮೌಲ್ಯವನ್ನು ಅಳಿಸಿಹಾಕಬಹುದು, ಇದರಿಂದ ವ್ಯಾಪಾರಿಯು ಗೊಂದಲಕ್ಕೀಡಾಗಬಹುದು ಮತ್ತು ತಪ್ಪಿತಸ್ಥ ಮಾಡ್ಯೂಲ್ವು ಹಾನಿಕಾರಕವಲ್ಲದಂತೆ ಕಾಣಿಸಬಹುದು.
ಹಂಚಿಕೆಯ ಕಾನ್ಫಿಗರೇಶನ್ ಟೇಬಲ್ ಏಕೆ ಮುಖ್ಯ
PrestaShop ಪ್ರತಿಯೊಂದು ಮಾಡ್ಯೂಲ್ನ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಕೇವಲ ಒಂದು 'key' ಮತ್ತು 'value' ಅನ್ನು ಹೊಂದಿರುವ ಒಂದೇ ಟೇಬಲ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಯಾವ ಮಾಡ್ಯೂಲ್ ಒಂದು ರೋವನ್ನು (row) ರಚಿಸಿದೆ ಎಂದು ದಾಖಲಿಸುವ ಯಾವುದೇ ಕಾಲಮ್ ಈ ಟೇಬಲ್ನಲ್ಲಿ ಇಲ್ಲ ಮತ್ತು ಇದು ಯಾವುದೇ ಹೆಸರಿಸುವ ನಿಯಮವನ್ನು (naming convention) ಕಡ್ಡಾಯಗೊಳಿಸುವುದಿಲ್ಲ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಒಂದೇ ರೀತಿಯ ಕೀಗಳನ್ನು ಬಳಸುವ ಎರಡು ಮಾಡ್ಯೂಲ್ಗಳು—ಉದಾಹರಣೆಗೆ “width” ಅಥವಾ “API_DATE_FROM”—ಒಂದೇ ಡೇಟಾಬೇಸ್ ರೋವನ್ನು ಓದುವ ಮತ್ತು ಬರೆಯುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ. ಕೊನೆಯದಾಗಿ ಬರೆಯಲ್ಪಟ್ಟ ಮೌಲ್ಯವು ಉಳಿಯುತ್ತದೆ ಮತ್ತು ನಂತರದ ಯಾವುದೇ ಡಿಲೀಟ್ ಆಪರೇಷನ್ ಎರಡೂ ಮಾಡ್ಯೂಲ್ಗಳಿಗಾಗಿ ಆ ರೋವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಅನ್ಇನ್ಸ್ಟಾಲ್ ಕೋಡ್ ಡೇಟಾ ಅಳಿಸುವ ಸಾಧನವಾಗಿದಾಗ
ಒಂದು ಸಾಮಾನ್ಯ ಅನ್ಇನ್ಸ್ಟಾಲ್ ವಿಧಾನವು ಈ ರೀತಿ ಇರುತ್ತದೆ:
public function uninstall()
{
return Configuration::deleteByName('width');
}
ಇದರ ಉದ್ದೇಶ ಮಾಡ್ಯೂಲ್ನ ಸ್ವಂತ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದಾಗಿದೆ, ಆದರೆ ಕೀ (key) ಅನ್ನು ನೇಮ್ಸ್ಪೇಸ್ (namespace) ಮಾಡದ ಕಾರಣ, ಈ ಸ್ಟೇಟ್ಮೆಂಟ್ “width” ಎಂದು ಕರೆಯಲ್ಪಡುವ ಯಾವುದೇ ರೋವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಯಾವುದೇ ಎಚ್ಚರಿಕೆ (warning) ದಾಖಲಾಗುವುದಿಲ್ಲ, ಯಾವುದೇ ಎಕ್ಸೆಪ್ಶನ್ (exception) ಉಂಟಾಗುವುದಿಲ್ಲ; ಆ ರೋವು ಸುಮ್ಮನೆ ಮಾಯವಾಗುತ್ತದೆ. ವ್ಯಾಪಾರಿಯ ಇತರ ಮಾಡ್ಯೂಲ್ ತನ್ನ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮೌನವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಿಚಿತ್ರವಾಗಿ ವರ್ತಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು.
ವರ್ಷನ್ ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವಾಗ ಈ ಸಮಸ್ಯೆ ಹೆಚ್ಚು ಅಪಾಯಕಾರಿಯಾಗುತ್ತದೆ. ವರ್ಷನ್ 1.0 ರಿಂದ 2.0 ಕ್ಕೆ ಬದಲಾಗುವ ಡೆವಲಪರ್ MY_MODULE_WIDTH ನಂತಹ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಿರುವ ಕೀ ಅಡಿಯಲ್ಲಿ ಮೌಲ್ಯಗಳನ್ನು ಉಳಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಹಳೆಯ, ಪ್ರಿಫಿಕ್ಸ್ ಇಲ್ಲದ ಎಂಟ್ರಿಗಳನ್ನು "ಕ್ಲೀನ್ ಅಪ್" ಮಾಡಲು, ಅವರು ಕೇವಲ ಹಳೆಯ ಡೇಟಾವನ್ನು ಮಾತ್ರ ತೆಗೆದುಹಾಕುತ್ತಿದ್ದಾರೆ ಎಂದು ನಂಬಿ, ಅನ್ಇನ್ಸ್ಟಾಲ್ ರೂಟೀನ್ಗೆ ಡಿಲೀಟ್ ಕರೆಯನ್ನು ಸೇರಿಸುತ್ತಾರೆ. ವಾಸ್ತವದಲ್ಲಿ, ಅವರು ಅದೇ ಸಾಮಾನ್ಯ ಕೀ ಅಡಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಇತರ ಎಕ್ಸ್ಟೆನ್ಶನ್ಗಳ ಡೇಟಾವನ್ನು ಸಹ ಅಳಿಸುತ್ತಿದ್ದಾರೆ.
ಆಡಿಟ್ನಲ್ಲಿ ಏನು ತಿಳಿದುಬಂದಿದೆ
57 ಸಾರ್ವಜನಿಕ ಮಾಡ್ಯೂಲ್ ರೆಪೊಸಿಟರಿಗಳ (repositories) ಆಡಿಟ್ ಒಂದು ಪುನರಾವರ್ತಿತ ಮಾದರಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸಿದೆ:
- ಅನೇಕ ಮಾಡ್ಯೂಲ್ಗಳು ಮಾಡ್ಯೂಲ್ನ ಹೆಸರಿನಿಂದ ಪಡೆದ ಯಾವುದೇ ಪ್ರಿಫಿಕ್ಸ್ ಇಲ್ಲದೆ “width”, “height”, ಅಥವಾ “API_DATE_FROM” ನಂತಹ ಸಾಮಾನ್ಯ ಕೀಗಳನ್ನು ಬಳಸುತ್ತವೆ.
- ಹಲವು ಅನ್ಇನ್ಸ್ಟಾಲ್ ವಿಧಾನಗಳು ಈ ಸಾಮಾನ್ಯ ಕೀಗಳನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿರುವ
Configuration::deleteByNameಕರೆಗಳನ್ನು ಒಳಗೊಂಡಿವೆ. - ಈ ಸಮಸ್ಯೆ ಕೇವಲ ಒಬ್ಬ ಡೆವಲಪರ್ಗೆ ಅಥವಾ ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ಮಾಡ್ಯೂಲ್ಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ; ಹಂಚಿಕೆಯ ಟೇಬಲ್ ವಿನ್ಯಾಸವು ಇದನ್ನು ವ್ಯವಸ್ಥಿತ ಅಪಾಯವನ್ನಾಗಿ (systemic risk) ಮಾಡುತ್ತದೆ.
ಮತ್ತೊಂದು ಮಾಡ್ಯೂಲ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂದು ಶಾಪ್ ಮಾಲೀಕರಿಗೆ ಎಚ್ಚರಿಸುವ ಯಾವುದೇ ಲಾಗ್ಗಳು ಅಥವಾ ದೋಷ ಸಂದೇಶಗಳನ್ನು ಆಡಿಟ್ನಲ್ಲಿ ಕಂಡುಬಂದಿಲ್ಲ. ವ್ಯಾಪಾರಿಯು ಇದನ್ನು ಕ್ಯಾಶ್ (cache) ಸಮಸ್ಯೆ ಅಥವಾ ಅವರ ಸ್ವಂತ ಕೋಡ್ನಲ್ಲಿನ ಬಗ್ ಎಂದು ಭಾವಿಸಬಹುದಾದ ಸೆಟ್ಟಿಂಗ್ಗಳ ಹಠಾತ್ ನಷ್ಟವೇ ಏಕೈಕ ಲಕ್ಷಣವಾಗಿದೆ.
ಮಾಡ್ಯೂಲ್ ಡೆವಲಪರ್ಗಳಿಗಾಗಿ ಸುರಕ್ಷಿತ ಪದ್ಧತಿಗಳು
- ಪ್ರತಿಯೊಂದು ಕೀ ಅನ್ನು ನೇಮ್ಸ್ಪೇಸ್ (Namespace) ಮಾಡಿ – ಪ್ರತಿಯೊಂದು ಕಾನ್ಫಿಗರೇಶನ್ ಕೀಗೆ ಮಾಡ್ಯೂಲ್ನ ತಾಂತ್ರಿಕ ಹೆಸರನ್ನು ಸೇರಿಸಿ (ಉದಾಹರಣೆಗೆ,
my_module_width). ಇದು ಪ್ರತ್ಯೇಕ ಮಾಲೀಕತ್ವದ ಕಾಲಮ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗದೆ ವಿಶಿಷ್ಟ ಗುರುತನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. - ಹಳೆಯ, ಪ್ರಿಫಿಕ್ಸ್ ಇಲ್ಲದ ಕೀಗಳನ್ನು ಅಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ – ಟೇಬಲ್ನಲ್ಲಿ ಕೆಲವು ಹಳೆಯ ರೋಗಳನ್ನು ಬಿಡುವುದು ಸ್ಟೋರೇಜ್ನಲ್ಲಿ ಯಾವುದೇ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಅಡ್ಡಪರಿಣಾಮದ ಅಪಾಯವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
- ಅಳಿಸುವ ಮೊದಲು ಮಾಲೀಕತ್ವವನ್ನು ಪರಿಶೀಲಿಸಿ – ಡಿಲೀಟ್ ಮಾಡುವುದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಾಗಿದ್ದರೆ, ಮೊದಲು ಕೀ ಮೌಲ್ಯವನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಕೋಡ್ ಮೂಲಕ ಸೆಟ್ ಮಾಡಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ (ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್ಗೆ ಮಾತ್ರ ತಿಳಿದಿರುವ ಮಾರ್ಕರ್ ಮೌಲ್ಯವನ್ನು ಸಂಗ್ರಹಿಸಿ).
- ಅನ್ಇನ್ಸ್ಟಾಲ್ ವಿಧಾನಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಿ – ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ
deleteByNameಕರೆಗಳಿಗಾಗಿ ಹುಡುಕಿ. ಪ್ರತಿಯೊಂದು ಸಂದರ್ಭವನ್ನು ಕೀ ವಿಶಿಷ್ಟವಾಗಿ ನೇಮ್ಸ್ಪೇಸ್ ಆಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪರೀಕ್ಷಿಸಬೇಕು. - ಹೆಸರಿಸುವ ನಿಯಮವನ್ನು ದಾಖಲಿಸಿ – ಮಾಡ್ಯೂಲ್ನ README ನಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತ ಮಾರ್ಗಸೂಚಿಯನ್ನು ಸೇರಿಸಿ, ಇದರಿಂದ ಭವಿಷ್ಯದ ಕೊಡುಗೆದಾರರು (contributors) ಪ್ರಿಫಿಕ್ಸ್ಡ್ ಕೀಗಳ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಅಕಸ್ಮಾತ್ ಕ್ರಾಸ್-ಮಾಡ್ಯೂಲ್ ಡಿಲೀಟ್ಗಳಿಗಾಗಿ ಪರೀಕ್ಷಿಸುವುದು
ಲೈವ್ ಶಾಪ್ಗೆ ತಲುಪುವ ಮೊದಲು ಈ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ವಿಧಾನ:
- ಬೇರೆ ಮಾಡ್ಯೂಲ್ಗೆ ಸೇರಿದ ಕೀ ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್ ಟೇಬಲ್ ಅನ್ನು ಸೀಡ್ (Seed) ಮಾಡಿ (ಉದಾಹರಣೆಗೆ,
other_module_setting=>test). - ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ (controlled environment) ಮಾಡ್ಯೂಲ್ನ ಅನ್ಇನ್ಸ್ಟಾಲ್ ರೂಟೀನ್ ಅನ್ನು ರನ್ ಮಾಡಿ.
- ಅನ್ಇನ್ಸ್ಟಾಲ್ ಪೂರ್ಣಗೊಂಡ ನಂತರ ಸೀಡ್ ಮಾಡಿದ ಕೀ ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ (Assert).
ಮಾಡ್ಯೂಲ್ನ ಯೂನಿಟ್-ಟೆಸ್ಟ್ ಸೂಟ್ನಲ್ಲಿ (unit-test suite) ಈ ಪರಿಶೀಲನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದರಿಂದ, ಭವಿಷ್ಯದಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಯು ಅಕಸ್ಮಾತ್ deleteByName ಕರೆಯನ್ನು ಪರಿಚಯಿಸಿದರೆ ಅದು ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಪರಿಶೀಲನೆಗೆ ಪ್ರೇರೇಪಿಸುತ್ತದೆ.
ಶಾಪ್ ಮಾಲೀಕರು ಯಾವುದನ್ನು ಗಮನಿಸಬೇಕು
ಸ್ಟೋರ್ ಮಾಲೀಕರು ಆಂತರಿಕ ಡೇಟಾಬೇಸ್ ರೋಗಳನ್ನು ಅಪರೂಪವಾಗಿ ನೋಡುತ್ತಾರೆ, ಆದರೆ ಅವರು ಲಕ್ಷಣವನ್ನು ಗುರುತಿಸಬಹುದು: ಒಂದು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಡಿಸೇಬಲ್ ಅಥವಾ ಅನ್ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿದ ನಂತರ, ಮತ್ತೊಂದು ಎಕ್ಸ್ಟೆನ್ಶನ್ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಡಿಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳಿಗೆ ಮರಳುತ್ತದೆ. ಹಾಗೆ ಸಂಭವಿಸಿದರೆ, ಮಾಡ್ಯೂಲ್ನ ಅನ್ಇನ್ಸ್ಟಾಲ್ ಕೋಡ್ ಗ್ಲೋಬಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಟೇಬಲ್ ಅನ್ನು ಗೌರವಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಡೆವಲಪರ್ ಬಳಿ ಕೇಳಿ. ಮಾಡ್ಯೂಲ್ ಬಳಸುವ ಎಲ್ಲಾ ಕಾನ್ಫಿಗರೇಶನ್ ಕೀಗಳ ಪಟ್ಟಿಯನ್ನು ಕೇಳಿ; ಸ್ಪಷ್ಟವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಇಲ್ಲದ ಯಾವುದೇ ಕೀ ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತವಾಗಿದೆ (red flag).
ಸಾರಾಂಶ
PrestaShop ನ ವಿನ್ಯಾಸವು ಕಾನ್ಫಿಗರೇಶನ್ ಟೇಬಲ್ ಅನ್ನು ಒಂದು ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅಜಾಗರೂಕತೆಯ ಅನ್ಇನ್ಸ್ಟಾಲ್ ಪ್ರಕ್ರಿಯೆಯು ಇನ್ನೊಂದು ಮಾಡ್ಯೂಲ್ನ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಯಾವುದೇ ಕುರುಹು ಇಲ್ಲದೆ ಅಳಿಸಿಹಾಕಬಹುದು. ಕೀಗಳಿಗೆ ನೇಮ್ಸ್ಪೇಸ್ ನೀಡುವುದು, ಅತಿಯಾದ ಕ್ಲೀನಪ್ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸುವುದು ಮತ್ತು ಇತರ ಎಂಟ್ರಿಗಳನ್ನು ರಕ್ಷಿಸುವ ಸರಳ ಪರೀಕ್ಷೆಯನ್ನು ಸೇರಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್ಗಳು ಮೌನವಾಗಿ ಡೇಟಾ ಕಳೆ//ಹೋಗುವುದನ್ನು ತಡೆಯಬಹುದು ಮತ್ತು ವ್ಯಾಪಾರಿಗಳ ಶಾಪ್ಗಳನ್ನು ಸ್ಥಿರವಾಗಿಡಬಹುದು. ಇದಕ್ಕೆ ಬೇಕಾಗುವ ಶ್ರಮ ಬಹಳ ಕಡಿಮೆ, ಆದರೆ ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಕಳೆ//ಹೋದರೆ ಉಂಟಾಗುವ ನಷ್ಟ—ಗ್ರಾಹಕರ ದೂರುಗಳು, ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳು ಮತ್ತು ಹಾನಿಗೊಳಗಾದ ಪ್ರತಿಷ್ಠೆ—ಅದಕ್ಕಿಂತ ಬಹಳ ಹೆಚ್ಚಿರಬಹುದು.