Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!

30.04.2024

ID в базах Apple

…А наробило мені проблем вчора те, що чомусь в обʼєктів в базах CoreData / SwiftData немає нормальних ID. Тобто, ідентифікатор є — має клас PersistentModelIdentifier. Але він не кодується ані в число, а ні в рядок. Спроба кодувати його в JSON видає ось таке:

{
  "implementation": {
    "isTemporary": false,
    "storeIdentifier": "345F4CA3-CCAE-49D8-8434-EFECA9056B68",
    "primaryKey": "p2640",
    "uriRepresentation": "x-coredata://345F4CA3-CCAE-49D8-8434-EFECA9056B68/Sample/p2640",
    "entityName": "Sample"
  }
}

Так, все це з одного ID. Бачите, теоретично, наприклад, поле urlRepresentation могло б використовуватись як рядкове кодування. Але його не дають повернути назад у PersistentModelIdentifier (або я не знайшов, як.) Ба більше, навіть отримати це значення я не можу — тільки через JSON. Звісно, весь цей JSON разом можна декодувати в ID, але він абсурдно надлишковий.

… В базах Apple ID не дуже потрібний, оскільки вони мають обʼєктну природу. Замість ID ми зберігаємо просто посилання на інші обʼєкти. Та це дійсно дуже круто — бо дозволяє не думати про завантаження асоціацій.

Але — деколи ID все ж потрібні (наприклад, для побудови власних URL чи для експорту.) Що я роблю: генерую для кожного обʼєкта UUID, який зберігається окремим полем. Використовується він тільки для експорту. Чому UUID, які я так не люблю? Бо є ймовірність збігів (якщо застосунок встановлений на двох пристроях); плюс для генерації UUID є стандартний клас. А швидкодія мене мало турбує, бо ці UUID не є первинним ключем.

(PS: якщо придивитись, то ID CoreData теж містить в себе UUID. Але, наскільки я розумію, це UUID пристрою, а локально обʼєкти мають чисельні ідентифікатори.)