Thanks for clarifying . This is what I think now,
The reason a separate /collection/$UUID page makes sense is that MB collection data doesn’t live in LB’s database — so the existing playlist routes can’t be reused since they depend on LB’s own playlist.playlist table.
And now we want same pattern as listenbrainz.org/artist/$UUID which reads directly from the MB database without storing anything in LB as you mentioned
Here’s the flow I have in mind:
-
from LB they click Import → select MusicBrainz → see a list of their MB recording collections → click one → land on
/collection/$UUID -
The page displays the collection as a read-only track list fetched directly from MB database , The user can listen right there.
-
If user want an editable personal copy as a playlist, they click “Save as Playlist” — only then does anything get written to LB’s database via the existing
POST /1/playlist/createendpoint.
On the backend with two endpoints needed since the frontend can’t directly query MB’s database ,one to list the user’s MB recording collections, and one to fetch tracks for a selected collection. Both will use mb_engine with raw SQL since no existing helpers cover collections.A helper like fetch_collection_tracks(collection_mbid) running sql against MB database via mb_engine can be created .
Does this match what you had in mind?