Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!19.07.2023
Приховані проблеми з 64-бітними ідентифікаторами
Коли я рекомендував використати 64-бітні числа як ідентифікатори, я упустив важливий нюанс, а саме те, що не всі мови та середовища їх підтримують. Навіть в наш час, коли майже кожний компʼютер має 64-бітний процесор — від смартфона до сервера.
Ви маєте ретельно перевірити, що ID не проходять в числовій формі там, де мова не підтримує 64-бітні цілі числа. Я впевнений, що такі місця у вас є, принаймні тому, що JavaScript їх не підтримує. Але перевіряти треба все, бо як я писав, наші проблеми почалися не з JavaScript, а з закритої цільової мови. Щоб не створювати додаткових ризиків, краще не тільки перетворювати ці ID на рядки, а й робити їх очевидно не чисельного вигляду — хоча б додати префікс.
При чому, в типовій ситуації надто велике значення ID не призведе до винятку. ID залишиться числом — цілим числом — він тільки округлиться до іншого значення. Абсолютно непомітно.
Поламані ID - це не так погано на фронтенді, бо там вони призведуть хіба що до тимчасової втрати доступу користувача до своїх ресурсів. Але всередині системи це вкрай ризикова помилка, бо ID зазвичай нема чим перевірити, та якщо вони потрапляють в базу, відновити дійсну картину буде складно.
Та ще загальна рекомендація — якщо аналітики знайшли вам баг в даних за допомогою деякого SQL запиту, треба перетворити цей запит на постійний моніторинг. Добре мати набір SQL-інваріантів, які помітять розбіжності до того, як це зроблять аналітики (або гірше, користувачі.)