Модель даних

Каталог bae — звичайний SQLite, оголошений для coven таблиця за таблицею: синхронізовані таблиці їдуть на кожен пристрій, який може їх читати; неоголошені таблиці ніколи не залишають пристрій. Цей поділ — найважливіше рішення моделі даних, тому сторінка побудована навколо нього.

Граф каталогу

Синхронізоване серце схеми:

artists, albums, works: шар групування. Альбом збирає свої релізи й указує на основний; works утворюють граф батько/дитина для класичної структури.
** releases **: центральний об’ єкт, один рядок на кожну імпортовану копію. Вміщує дані щодо натиснення (мітка, номер каталогу, штрих- код, країна, формат, рік), додатковий вибір походження метаданих, геш- код вмісту імпортованої теки і виміряну гучність альбому. Відсутність походження означає, що метадані було введено безпосередньо; зовнішнє походження називає точне видання джерела, а Теги файлів записує локальне джерело знімків.
** release_identities **: точні зовнішні профільні дані щодо випуску * є *. Відсутність рядків означає відсутність зовнішніх профільних даних. Кожен рядок має назву випуску MusicBrainz або Discogs і групи випусків, а випуск може мати профільні дані з обох джерел одночасно. Цей параметр не пов’ язано з походженням: профільні дані можна змінювати, не стверджуючи, що поточні метадані, які можна редагувати, було скинуто з цього джерела.
tracks з track_artists, плюс release_artist_roles і track_artist_roles: списки треків і кредити, кожен кредит позначений своїм джерелом.
track_works, work_parts, work_artists: записи, пов’язані з творами, які вони виконують.
audio_formats і audio_format_segments: специфікації відтворення. Для кожного треку: кодек, частота дискретизації, бітова глибина, канали, виміряна гучність і пік, а також довжини прегапів. Сегменти відображають трек на впорядковані байтові й семплові вікна його вихідних файлів; саме так трек із CUE-рипу, включно з прегапом, може охоплювати ділянки одного великого файла або кількох файлів.
release_files, covers, artist_images: таблиці, що несуть blobs. Рядки є записами каталогу; байти живуть у blob-шарі coven (див. нижче).
people, ratings, history, playlists, playlist_entries: профіль кожної людини і те, що вона записує для себе. Це таблиці власника: змінювати їх можуть лише пристрої їхнього автора. Рядки history і playlists живуть кожен або в спільному сховищі домогосподарства, або в приватному колі людини.

Синхронізоване і локальне

Кожна таблиця вище синхронізується безумовно: рядки локального релізу потрапляють на кожен пристрій так само, як рядки будь-якого іншого релізу, тож кожен пристрій знає, чим володіє домогосподарство, а оцінка чи запис плейлиста, що вказує на трек локального релізу, вказує на рядок, який може прочитати кожен пристрій. На пристрої імпорту лишаються лише аудіо релізу й шляхи, де воно лежить. Кожна таблиця оголошується з ідентичністю рядка, аудиторією, ознакою таблиці власника й файлами, які вона несе; тест тримає оголошення точно на цьому списку.

Повністю локальні таблиці, ніколи не оголошені для coven:

playback_state: поточний трек, позиція, черга, гучність, shuffle і repeat. Відтворення — факт пристрою.
Таблиці сканування й імпорту: відстежувані папки, сканування, кандидати на імпорт і їхні чернетки.
source_release і таблиці під нею: те, що bae витягнув з кожного отриманого релізу MusicBrainz і Discogs — дані альбому й пресингу, повний трекліст з учасниками й творами, варіанти обкладинки та те, як його називають інші каталоги, — з ключем за релізом постачальника, а не за локальним релізом. Сирий JSON не зберігається; будь-який пристрій може отримати реліз знову.
local_release_files: шляхи файлів і час зміни локального релізу на цьому пристрої.
local_history: прослуховування з часу, коли людина цього пристрою ще не мала профілю, які переходять у її приватне коло, щойно профіль створено.

Редагування двох пристроїв об’єднуються клітинка за клітинкою, і пізніше редагування виграє клітинку, яку змінили обидва. coven веде облік об’єднання у власних таблицях, тож таблиці bae не несуть стовпців годинника.

Blobs

Аудіо й зображення — це файли coven, кожен вид — простір імен зі своїм бюджетом кешу пристрою: release_files (20 GiB), covers (512 MiB), artist_images (256 MiB) і avatars (64 MiB). Рядок посилається на свій файл за ідентифікатором файлу coven: file у release_files, covers і artist_images та avatar_id у people. Розмір, хеш вмісту й розташування файлу належать coven і читаються через з’єднання з coven_files.

Файли релізу належать користувачу: файли локального релізу — це файли користувача за їхніми початковими шляхами, записані в local_release_files, і його рядки не посилаються на жоден файл coven. Переміщення релізу в хмару одним записом готує кожен файл у coven і спрямовує кожен рядок на його файл; щойно збережено останній, coven переводить їх усі разом у хмару, а інші пристрої забирають кожен у кеш під час першого читання. Обкладинки, зображення виконавців і аватари належать bae: bae створює байти (обкладинки перемальовуються як JPEG-мініатюри не ширші за 600px), а пристрій забирає кожне, коли його вперше показано, і тримає, доки бюджет його простору імен його не витіснить.

Кожен файл завантажується зашифрованим під випадковим іменем, за шляхом, зафіксованим під час його підготовки, тож пізніше перейменування ніколи не переміщує об’єкт. Файл ніколи не змінює своїх байтів: нове зображення — це новий файл.

Ідентичність рипу

Кожен імпорт створює реліз із новим випадковим ідентифікатором і власними рядками треків та файлів. Кожен пристрій записує в local_release_origin SHA-256 відсортованих відносних шляхів, розмірів і часу зміни файлів, які прочитав кожен його імпорт; цей запис ніколи не синхронізується. Папка, хеш якої записав цей пристрій, є на вкладці завершених імпортів, куди б її не перемістили, а її рядок називає єдиний реліз, імпортований з неї. Повторний імпорт тих самих файлів на цьому пристрої завершується помилкою, а вкладка завершених імпортів не пропонує повторного імпорту.