1. Kirish
Loyiha ustida ishlash jarayonida biror talabni amalga oshirayotganda boshqa muammoni aniqlash odatiy hol. Ushbu maqolada My Page sahifasiga bo‘limga xos rol ma’lumotlarini qo‘shish bo‘yicha mijoz talabini amalga oshirish vaqtida ko‘p tilli bo‘lim nomlari ma’lumotlarini saqlashdagi xatoni aniqlash va yaxshilash tajribasini umumlashtiraman.
2. Muammo haqida umumiy ma’lumot
Muammo My Page sahifasida bo‘limga xos rol ma’lumotlarini ko‘rsatish funksiyasini qo‘shish vaqtida aniqlandi. Mijoz talabi foydalanuvchilarga My Page sahifasida o‘zlari tegishli bo‘lgan bo‘limni va shu bo‘limdagi rollarini ko‘rish imkonini berishdan iborat edi.
Frontend tomonda vazifa backend qaytargan bo‘lim nomi va rol ma’lumotlarini shunchaki ko‘rsatishdan iborat edi. Biroq ishlab chiqish jarayonida ayrim bo‘lim nomlari bo‘sh qiymat sifatida qaytarilayotganini payqadik. Dastlab frontenddagi mapping muammosi yoki javob ma’lumotlarini qayta ishlashdagi xatodan shubhalandik. Ammo API javobini tekshirgach, frontend bu qiymatlarni olib tashlamaganini, balki backendning o‘zi qaytargan bo‘lim nomlari bo‘sh ekanini aniqladik.
Shundan so‘ng backenddagi so‘rov mantiqini tekshirdik. So‘rov mantiqi bo‘lim nomini joriy ekran tili bo‘lgan ko asosida olardi. Bu xatti-harakatning o‘zi odatiy edi. Muammo DBda saqlangan ko‘p tilli ma’lumotlarda edi. DBni bevosita tekshirganimizda, koreyscha bo‘lim nomlari ko til kodi ostida emas, en til kodi ostida saqlanganini aniqladik.
Boshqacha qilib aytganda, ekran koreyscha bo‘lim nomini ko ostidan qidirgan, ammo amaldagi koreyscha qiymat en ostida saqlangani sababli u bo‘sh qiymat sifatida ko‘ringan.
3. Asosiy sabab tahlili
Muammoni tekshirish davomida avvalo backend bo‘lim nomlarini so‘rash uchun qaysi til kodidan foydalanishini tekshirdik. So‘rov tomoni koreys tili kodi bo‘lgan ko asosida qiymatlarni olayotgani sababli, API javobining bo‘sh bo‘lishiga so‘rov shartidan ko‘ra saqlangan ma’lumot sabab bo‘lishi ehtimoli yuqori deb xulosa qildik.
Bo‘lim yaratish jarayonini kuzatib, hospital integration batch yangi bo‘limni Stage sifatida ro‘yxatdan o‘tkazishda umumiy ro‘yxatdan o‘tkazish usulidan foydalanayotganini aniqladik. Odatiy holatda bu usul Spring'ning LocaleContextHolder obyektidan joriy lokalni oladi va undan til kodi sifatida foydalanadi.
public Tenant registerTenant(TenantCdo tenantCdo) {
return registerTenant(
tenantCdo,
LocaleContextHolder.getLocale().getLanguage()
);
} Web so‘rovida lokalni so‘rov konteksti orqali aniqlash mumkin, ammo batch brauzerda foydalanuvchi tomonidan bevosita boshlangan jarayon emas. Shu sababli batch ishga tushgan vaqtda foydalanuvchining aniq so‘rov lokali mavjud bo‘lmagan va LocaleContextHolder JVMning standart lokalidan foydalangan. Ushbu muhitda standart lokal en qilib o‘rnatilgan edi, shuning uchun hospital adapter taqdim etgan koreyscha bo‘lim nomi en kaliti ostida saqlandi.
4. Yangi bo‘limni ro‘yxatdan o‘tkazish jarayonini yaxshilash
Koddagi o‘zgarishlar hospital integration batchida yangi bo‘limni Stage sifatida ro‘yxatdan o‘tkazish jarayoniga qaratildi. Muammoli ma’lumot batch yangi bo‘lim yaratganda hosil bo‘ladigan tarjima ma’lumoti bo‘lgani sababli, bo‘limlarni sinxronlashtirishning umumiy mantiqiga katta o‘zgarish kiritish o‘rniga, yangi Stage ro‘yxatga olish vaqtida til kodini aniq uzatishga qaror qildik.
Mavjud registerTenant(TenantCdo) usuli web so‘rovlari uchun ishlashda davom etishi uchun saqlab qolindi. Buning o‘rniga, so‘rov lokali mavjud bo‘lmagan yoki ishonchsiz bo‘lgan batch va sinxronlashtirish jarayonlarida til kodini bevosita uzatish imkonini beruvchi overload qo‘shdik.
public Tenant registerTenant(TenantCdo tenantCdo) {
return registerTenant(
tenantCdo,
LocaleContextHolder.getLocale().getLanguage()
);
}
public Tenant registerTenant(
TenantCdo tenantCdo,
String languageCode
) {
Tenant tenant = Tenant.fromCdo(
tenantCdo,
languageCode
);
return tenant;
} Yangi Stage yaratishning amaldagi jarayonida hospital adapter taqdim etgan bo‘lim nomi koreys tilida ekaniga asoslanib, ko aniq ko‘rsatildi.
return (Stage) tenantLogic.registerTenant(stageCdo, "ko"); Bu batchda yangi yaratilgan bo‘lim ma’lumotlarini mavjud web so‘rovi jarayoniga ta’sir qilmagan holda mo‘ljallangan til kodi ostida saqlash imkonini berdi. Mavjud Stage nomlarini o‘zgartirish va boshqa yangilash jarayonlarini ham o‘z ichiga olgan barcha oqimlarni o‘zgartirish o‘rniga, zarur ishlov berishni muammo yuzaga kelgan yangi ro‘yxatdan o‘tkazish nuqtasining o‘ziga qo‘shdik.
5. Ma’lumotlarni tuzatish uchun SQL
Koddagi o‘zgarishlar shu vaqtdan boshlab yaratiladigan bo‘lim ma’lumotlarini tuzatgani sababli, avval noto‘g‘ri saqlangan mavjud ma’lumotlarni alohida tuzatish kerak edi.
DBni tekshirgach, muammo faqat ishlab chiqish muhiti bilan cheklanmaganini aniqladik. U ishlab chiqish, staging va production muhitlarining barchasida yuz bergan, shuningdek bir xil qiymatlar nafaqat manba jadvalida, balki so‘rovlar samaradorligi uchun sozlangan alohida so‘rov ma’lumotlarida ham aks etgan.
Ma’lumotlarni tuzatish uchun SQL production ma’lumotlariga ta’sirni minimallashtirish maqsadida yozildi. language_code = 'en' bo‘lgan har bir yozuvni shunchaki ko ga o‘zgartirish xavfli deb hisobladik, shuning uchun quyidagi shartlarni birgalikda qo‘lladik.
- Faqat bo‘lim ma’lumotlariga mos keladigan elementlar o‘zgartiriladi.
- Faqat yaroqli ma’lumotlar o‘zgartiriladi.
- Faqat til kodi en sifatida saqlangan ma’lumotlar o‘zgartiriladi.
- Faqat tizim akkaunti tomonidan ro‘yxatdan o‘tkazilgan ma’lumotlar o‘zgartiriladi.
- Xuddi shu bo‘lim uchun ko tarjimasi allaqachon mavjud bo‘lgan yozuvlar chiqarib tashlanadi.
Amaldagi tuzatish so‘rovi quyidagi shaklda yozildi.
update cm_tenant_translation tt
set language_code = 'ko',
modified_by = 'system-fix',
modified_on = now()
from cm_tenant t
where t.id = tt.tenant_id
and t.tenant_type = 'STAGE'
and tt.valid_yn = true
and tt.language_code = 'en'
and tt.registered_by = 'system'
and not exists (
select 1
from cm_tenant_translation ko
where ko.tenant_id = tt.tenant_id
and ko.language_code = 'ko'
and ko.valid_yn = true
); Ushbu shartlar haqiqiy inglizcha ma’lumotlarni yoki bevosita foydalanuvchilar tomonidan ro‘yxatdan o‘tkazilgan ma’lumotlarni noto‘g‘ri o‘zgartirish xavfini kamaytirdi. Amaldagi Flyway skriptida tuzatishlar nafaqat manba jadvali bo‘lgan cm_tenant_translationga, balki so‘rovlar uchun ishlatiladigan qm_tenant_view ichidagi namei18n va qm_membership_view ichidagi tenant_namei18n jadvallariga ham qo‘llandi.
update qm_tenant_view v
set namei18n = (v.namei18n - 'en')
|| jsonb_build_object('ko', v.namei18n ->> 'en'),
modified_on = now()
where v.tenant_type = 'STAGE'
and v.namei18n ? 'en'
and not (v.namei18n ? 'ko');
update qm_membership_view m
set tenant_namei18n = (m.tenant_namei18n - 'en')
|| jsonb_build_object('ko', m.tenant_namei18n ->> 'en'),
modified_on = now()
where m.tenant_type = 'STAGE'
and m.tenant_namei18n ? 'en'
and not (m.tenant_namei18n ? 'ko'); 6. Qo‘llash va tekshirish
Ishlab chiqish muhitida avval so‘rov yordamida ma’lumotlarni tuzatdik, so‘ng My Page ekranida bo‘limga xos rol ma’lumotlari to‘g‘ri ko‘rsatilayotganini tekshirdik. Bu bosqichda biz faqat DB qiymatlarini tekshirib qolmadik, balki bo‘lim nomlari haqiqiy ekranda to‘g‘ri ko‘rinayotganini ham tasdiqladik. Foydalanuvchilar duch kelgan muammo ekranda yuz bergani sababli, yakuniy tekshiruv ham ekran nuqtayi nazaridan amalga oshirilishi kerak degan xulosaga keldik.
Staging va production muhitlarida o‘zgarishlarni so‘rovni qo‘lda ishga tushirish o‘rniga Flyway migratsiyasi orqali qo‘lladik. Ushbu ish production ma’lumotlariga ta’sir qilgani uchun bir xil skriptni versiyalar nazoratida saqlash va uni deployment tarixida qayd etish xavfsizroq deb hisobladik.
Avval stagingdagi Flyway qo‘llash natijalarini tekshirgach, o‘zgarishlarni production muhitiga qo‘lladik. Qo‘llashdan keyin maqsadli ma’lumotlar ko ga to‘g‘ri o‘zgartirilganini so‘rov orqali tekshirdik va bo‘lim nomlari ekranda to‘g‘ri ko‘rsatilayotganini ham tasdiqladik.
7. Olingan saboqlar va xulosa
Ushbu ish batch qayta ishlash jarayonlari oddiy foydalanuvchi so‘rovlaridan farqli taxminlar asosida loyihalanishi kerakligini yana bir bor tasdiqladi. Web so‘rovlarida tabiiy ravishda mavjud bo‘ladigan lokal, foydalanuvchi va header ma’lumotlari batchda mavjud bo‘lmasligi yoki muhitning standart qiymatlari bilan almashtirilishi mumkin. Agar batch tomonidan yaratiladigan ma’lumotlarning tili aniq bo‘lsa, so‘rov kontekstiga tayanishdan ko‘ra uni kodda aniq ko‘rsatish xavfsizroq.
Bundan tashqari, o‘zgarishlar doirasini toraytiruvchi shartlar ma’lumotlarni tuzatish jarayonida muhim ahamiyatga ega bo‘ldi. registered_by, tenant_type, valid_yn va mavjud ko ma’lumotlari bor-yo‘qligini tekshirish orqali faqat tizim batchi tomonidan yaratilgan maqsadli ma’lumotlarni tuzata oldik.
Ushbu holat My Page ekranida ayrim bo‘lim nomlarining bo‘sh qiymat sifatida qaytarilishi kabi kichik muammodan boshlandi. Biroq ekran, API javobi, DBda saqlash tuzilmasi va batchni ishga tushirish muhitini birgalikda tekshirish orqali haqiqiy sababni aniqladik hamda yangi ma’lumotlarni yaratish jarayoni bilan bir qatorda mavjud ma’lumotlarni ham tuzatdik.
Lynn