duckfromdiscord
commented
6 months ago I am trying to decide how to store the identifiers in the database. On one hand, the scrobble dictionary schema cannot/should not be changed, so we cannot include a new identifiers column. On the other hand, the precedent set by #149 is that identifiers should go into the extra field, but the extra field is hidden unless include_internal is specified.
I think the second option makes more sense, at least for storing the data. Retrieving the data is much more difficult, because we either include all of the include_internal data or none of it, and there is no parameter to /scrobbles that allows us to do so in the first place. We also cannot return the identifiers as a new tag in the API response, because we are returning the scrobble dict directly. So this is why, as @FoxxMD said, the scrobbles endpoint does not display stored musicbrainz tags.
Also, once identifier storing/retrieval is finished, it might make sense to move the musicbrainz tags alongside them. This also brings up the issue of potentially coming up with a set of standard key "names" for each identifier. For example identifiers['release_mbid'], and now identifiers['spotify_track_id'] maybe?
tl;dr: To display identifiers, no matter how we implement them, we need to include them in the scrobble dict. The question is how. We must either create a new column in the database, or add an option to pass-through the extra field when querying scrobbles through the API.
Adds functionality for third-party identifiers to maloja.
The goals: allow a scrobble client to embed identifiers (like Spotify ID, musicbrainz) with scrobble data, and allow them to be read as well.
Will fix #249.