Модель даних

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

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

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

artists, albums, works: шар групування. Альбом збирає свої релізи й указує на основний; works утворюють граф батько/дитина для класичної структури.
releases: центральна сутність, один рядок на видання. Несе факти видання (лейбл, номер каталогу, штрихкод, країна, формат, рік), джерело метаданих, content hash імпортованої папки й виміряну гучність альбому.
release_identities: чим реліз є, за кожним джерелом. Немає рядків — невідомий; рядок MusicBrainz або Discogs із release ID — точний; без нього — приблизний. Реліз може одночасно мати ідентичності в обох джерелах.
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 (див. нижче).

Синхронізоване, обмежене, локальне

Усе вищезазначене синхронізується, але не безумовно. releases оголошена як умовний корінь за своїм стовпцем remote: рядок релізу й усе його піддерево (доріжки, файли, кредити, формати, обкладинка) синхронізуються лише поки remote дорівнює true, тобто поки реліз керований хмарою. Перемикання релізу в керований публікує піддерево; некерований реліз лишається повністю на пристрої імпорту, хоча його схема синхронізована. Таблиці предків (artists, albums, works) синхронізуються лише поки якийсь синхронізований реліз ще посилається на них, тож пристрій ніколи не отримує виконавця, під яким нічого немає.

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

playback_state: поточний трек, позиція, черга, гучність, shuffle і repeat. Відтворення — факт пристрою.
imports: облік операцій імпорту.
release_metadata: архівований сирий JSON із MusicBrainz і Discogs, збережений для майбутньої переінтерпретації.

Кожна синхронізована таблиця несе стовпець _updated_at hybrid-logical-clock, регістр, за яким coven упорядковує одночасні редагування поле за полем; тест вимагає, щоб синхронізований набір і набір із цим годинником були точно однакові.

Blobs

Аудіо й зображення проходять через blob-шар coven у трьох просторах імен, кожен зі своїм бюджетом кешу пристрою: release_files (20 GiB), covers (512 MiB), artist_images (256 MiB).

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

У непрозорому домі blobs завантажуються під беззмістовними content keys. У browsable home кожен blob-рядок записує читабельний cloud path ({artist}/{album}/{filename} для аудіо, {album}/{release}/cover.{ext} для обкладинок), обчислений один раз під час завантаження, тож пізніше перейменування ніколи не переміщує об’єкт.

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

releases.content_hash — це SHA-256 над файловою структурою імпортованої папки (відносні шляхи й розміри), незалежно від того, де папка лежить на диску. Так bae розпізнає вже імпортований рип, коли він знову з’являється у відстежуваній папці, і так повторні імпорти знаходять реліз, який мають замінити.