2025-02-28, 04:20 AM
There's just that, or reading database dumps atm (there's a few good tools out there for working with raw leveldb databases). Sorry! Actual documentation has been on my to-do list for a while, but time continues to escape from us 
The extremely short version is that all keys are prefixed with a letter, and use null bytes (written as '/' in docs+comments) to separate out different fields in the keys. This allows us to effectively separate out sections of the database into namespaces. Most of these namespaces are quite straightfoward; e.g. 'data' keys are like "D/1234" (a prefix, D, a null byte spearator, a CBOR-encoded track id) and have values that contain things like times played, the track's filepath, etc.
Indexes are more complicated, since they rely on LevelDB storing keys on disk in a sorted order. Index keys are formatted, very very abstractly, like
I / grouping info / text / track id
Where the 'grouping info' is some data that identifies, e.g., you're in the 'Albums by artist' index and are viewing the records under a particular artist
Text is a https://en.cppreference.com/w/c/string/byte/strxfrm transformed version of the human-readable text (transformed such that a bytewise comparison yields a collated text order)
And track id is the track id.
Index record values are then just the human-readable text shown for each record.
If you'd like to know more, this file defines all the different record types we use: https://codeberg.org/cool-tech-zone/tang...ecords.cpp
And you may also be interested in the indexing logic; it's actually a fairly small little recursive algorithm, it's not as complicated as you might imagine: https://codeberg.org/cool-tech-zone/tang...x.cpp#L226
Obviously we should write proper docs for this eventually, but in the meantime we are very happy to answer any questions about it.
The extremely short version is that all keys are prefixed with a letter, and use null bytes (written as '/' in docs+comments) to separate out different fields in the keys. This allows us to effectively separate out sections of the database into namespaces. Most of these namespaces are quite straightfoward; e.g. 'data' keys are like "D/1234" (a prefix, D, a null byte spearator, a CBOR-encoded track id) and have values that contain things like times played, the track's filepath, etc.
Indexes are more complicated, since they rely on LevelDB storing keys on disk in a sorted order. Index keys are formatted, very very abstractly, like
I / grouping info / text / track id
Where the 'grouping info' is some data that identifies, e.g., you're in the 'Albums by artist' index and are viewing the records under a particular artist
Text is a https://en.cppreference.com/w/c/string/byte/strxfrm transformed version of the human-readable text (transformed such that a bytewise comparison yields a collated text order)
And track id is the track id.
Index record values are then just the human-readable text shown for each record.
If you'd like to know more, this file defines all the different record types we use: https://codeberg.org/cool-tech-zone/tang...ecords.cpp
And you may also be interested in the indexing logic; it's actually a fairly small little recursive algorithm, it's not as complicated as you might imagine: https://codeberg.org/cool-tech-zone/tang...x.cpp#L226
Obviously we should write proper docs for this eventually, but in the meantime we are very happy to answer any questions about it.
