Modello dati

Il catalogo di bae è SQLite ordinario, dichiarato a coven tabella per tabella: le tabelle sincronizzate portano un clock di conflitto e viaggiano verso ogni dispositivo; le tabelle non dichiarate non lasciano mai il dispositivo. La divisione è la decisione più portante del modello dati, quindi questa pagina è organizzata attorno a essa.

Il grafo del catalogo

Il cuore sincronizzato dello schema:

artists, albums, works: il livello di raggruppamento. Un album aggrega le sue release e punta a una principale; le opere formano un grafo padre/figlio per la struttura classica.
releases: l’entità centrale, una riga per ogni stampa; contiene i dati relativi alla stampa (etichetta, numero di catalogo, codice a barre, paese, formato, anno), la provenienza dei metadati opzionali, un hash del contenuto della cartella importata e l’audio misurato dell’album. Nessuna provenienza significa che i metadati sono stati inseriti direttamente; la provenienza esterna indica l’esatta versione originale, mentre Tag dei file registra una sorgente locale di snapshot.
release_identities: identità esterne esatte per ciò che una release è. Nessuna riga significa nessuna identità esterna. Ogni riga nomina una release e un gruppo di release MusicBrainz o Discogs, e una release può contenere identità in entrambe le fonti contemporaneamente. Questo è separato dalla provenienza: l’identità può cambiare senza affermare che i metadati modificabili correnti sono stati reimpostati da quella fonte.
tracks con track_artists, più release_artist_roles e track_artist_roles: liste tracce e crediti, ogni credito etichettato con la sua fonte.
track_works, work_parts, work_artists: registrazioni collegate alle opere che eseguono.
audio_formats e audio_format_segments: le specifiche di riproduzione. Per traccia: codec, frequenza di campionamento, profondità in bit, canali, sonorità e picco misurati, e lunghezze dei pregap. I segmenti mappano una traccia su finestre ordinate di byte e campioni dei suoi file sorgente, ed è così che la traccia di un rip CUE, pregap incluso, può attraversare regioni di un file grande o di più file.
release_files, covers, artist_images: tabelle che portano blob. Le righe sono voci di catalogo; i byte vivono nel livello blob di coven (vedi sotto).

Sincronizzato, vincolato, locale

Tutto quanto sopra si sincronizza, ma non incondizionatamente. releases è dichiarata come radice vincolata sulla sua colonna remote: una riga release e tutto il suo sottoalbero (tracce, file, crediti, formati, copertina) si sincronizzano solo mentre remote è true, cioè mentre la release è gestita nel cloud. Passare una release a gestita pubblica il sottoalbero; una release non gestita resta interamente sul dispositivo che l’ha importata, anche se il suo schema è sincronizzato. Le tabelle antenate (artists, albums, works) si sincronizzano solo mentre qualche release sincronizzata le riferisce ancora, così un dispositivo non riceve mai un artista senza nulla sotto.

Tabelle completamente locali, mai dichiarate a coven:

playback_state: traccia corrente, posizione, coda, volume, ordine casuale e ripetizione. La riproduzione è un fatto del dispositivo.
imports: tracciamento delle operazioni di importazione.
source_release_payloads: JSON grezzo archiviato da MusicBrainz e Discogs, con chiave di rilascio del fornitore piuttosto che di rilascio locale, supporta il reset esatto e la reinterpretazione senza modificare il grafico del catalogo sincronizzato.

Ogni tabella sincronizzata porta una colonna _updated_at di clock logico ibrido, il registro con cui l’unione campo per campo di coven ordina le modifiche concorrenti; un test impone che l’insieme sincronizzato e l’insieme con clock siano esattamente uguali.

Blob

Audio e immagini passano dal livello blob di coven in tre namespace, ciascuno con il proprio budget di cache per dispositivo: release_files (20 GiB), covers (512 MiB), artist_images (256 MiB).

I file delle release sono forniti dall’utente e memorizzati in cache su richiesta: per una release non gestita il blob è un riferimento esterno al file dell’utente nel suo percorso originale; per una gestita è un oggetto caricato recuperato in cache alla prima lettura. Copertine e immagini artista sono fornite dall’host e memorizzate in cache in anticipo: bae produce i byte (le copertine vengono renderizzate di nuovo come miniature JPEG larghe al massimo 600px), e ogni dispositivo le recupera al pull così le griglie si mostrino localmente.

Su una home opaca, i blob vengono caricati sotto chiavi di contenuto senza significato. Su una home esplorabile ogni riga blob registra un percorso cloud leggibile ({artist}/{album}/{filename} per l’audio, {album}/{release}/cover.{ext} per le copertine), calcolato una volta al caricamento così una rinomina successiva non sposta mai l’oggetto.

Identità di un rip

releases.content_hash è uno SHA-256 sulla struttura della cartella importata (percorsi relativi e dimensioni), indipendente da dove la cartella si trova su disco. È il modo in cui bae riconosce un rip già importato quando riappare in una cartella osservata, e il modo in cui le reimportazioni trovano la release che devono sostituire.