[GH-ISSUE #665] Compilation state #476

Closed
opened 2026-02-26 02:33:19 +03:00 by kerem · 2 comments
Owner

Originally created by @X-Ryl669 on GitHub (Oct 13, 2017).
Original GitHub issue: https://github.com/koel/koel/issues/665

Hi,

It seems you've removed the is_compilation column in Albums table and the corresponding logic in the code. I've hard time understanding the new model. If you don't mind, can you elaborate a bit on this change, since I guess, it'll be followed by more changes in the future?

Previously, if I understood correctly, we had an album who could have an artist_id mapping to, say, "Queen" but with a is_compilation flag set to zero/one. As soon as one of the song with this album referred to another artist, the is_compilation flag was set to one.

Currently, if I understand correctly, instead of changing the flag, you change the artist_id to various artist, and check for compilation by the condition artist_id == VariousArtistID, right ?

If so, how do you link the album with the "main" artist, since the album's artist_id is no more linked to "Queen" but to "Various Artist" ?

I understand it convenient to have only one way to figure out if an album is a compilation, but I wonder if it's something you wanted (this means having a lot of albums under "Various Artist" artist, but some album disappear from the main artist "Queen" where I expected them) or is it a temporary change before a larger change ?

In that case, I wonder if the song table shouldn't map to multiple artist_id instead (so instead of a single artist_id column, maybe rename to a artist_jam_id and add an artist_jam table with column (id not unique, artist_id). That way, one could find the "compilation" albums by selecting "Various Artist" or any of the participating artists' albums.

What do you think about that ?

Originally created by @X-Ryl669 on GitHub (Oct 13, 2017). Original GitHub issue: https://github.com/koel/koel/issues/665 Hi, It seems you've removed the `is_compilation` column in `Albums` table and the corresponding logic in the code. I've hard time understanding the new model. If you don't mind, can you elaborate a bit on this change, since I guess, it'll be followed by more changes in the future? Previously, if I understood correctly, we had an album who could have an `artist_id` mapping to, say, "Queen" but with a `is_compilation` flag set to zero/one. As soon as one of the song with this album referred to another artist, the `is_compilation` flag was set to one. Currently, if I understand correctly, instead of changing the flag, you change the `artist_id` to various artist, and check for compilation by the condition `artist_id == VariousArtistID`, right ? If so, how do you link the album with the "main" artist, since the album's `artist_id` is no more linked to "Queen" but to "Various Artist" ? I understand it convenient to have only one way to figure out if an album is a compilation, but I wonder if it's something you wanted (this means having a lot of albums under "Various Artist" artist, but some album disappear from the main artist "Queen" where I expected them) or is it a temporary change before a larger change ? In that case, I wonder if the song table shouldn't map to multiple `artist_id` instead (so instead of a single `artist_id` column, maybe rename to a `artist_jam_id` and add an `artist_jam` table with column (`id` not unique, `artist_id`). That way, one could find the "compilation" albums by selecting "Various Artist" or any of the participating artists' albums. What do you think about that ?
kerem closed this issue 2026-02-26 02:33:19 +03:00
Author
Owner

@phanan commented on GitHub (Oct 15, 2017):

The decision of the current implementation for album's compilation state traces back to the discussion in #664, which you and @YakovGoldberger are part of ;)

<!-- gh-comment-id:336719010 --> @phanan commented on GitHub (Oct 15, 2017): The decision of the current implementation for album's compilation state traces back to the discussion in #664, which you and @YakovGoldberger are part of ;)
Author
Owner

@X-Ryl669 commented on GitHub (Oct 16, 2017):

Yes you're right, of course. At the time you've shown us some diagram of the new entity relationship. I don't remember what was the conclusion for this discussion.

As I understand it, the song's artist relation is a 1:n relationship (there can be n artists per song). It can't be simple represented by a artist_id column in the songs table.
Thus, a new relationship table would be required, either a simple like this: artist_jam(song_id INTEGER /* refers song::id */, artist_id INTEGER /* refers artist::id */ ) and remove the artist_id column in songs.

Yet, what do you think about this change (if ok, I'll make a PR for it) ?

  1. Change part of the software that expect song's artist uniqueness to support array instead (that means Laravel's PHP Song & Album model and Media / File mainly, and the VueJS song & album store)
  2. Add a artist_jam table and migrate all songs' artist_id to artist_jam_id instead
  3. Change the api so that the song & album class has a array of artist id, instead of a simple integer value.
<!-- gh-comment-id:336846865 --> @X-Ryl669 commented on GitHub (Oct 16, 2017): Yes you're right, of course. At the time you've shown us some diagram of the new entity relationship. I don't remember what was the conclusion for this discussion. As I understand it, the song's artist relation is a 1:n relationship (there can be n artists per song). It can't be simple represented by a `artist_id` column in the `songs` table. Thus, a new relationship table would be required, either a simple like this: `artist_jam(song_id INTEGER /* refers song::id */, artist_id INTEGER /* refers artist::id */ )` and remove the `artist_id` column in `songs`. Yet, what do you think about this change (if ok, I'll make a PR for it) ? 1. Change part of the software that expect song's artist uniqueness to support array instead (that means Laravel's PHP Song & Album model and Media / File mainly, and the VueJS song & album store) 2. Add a artist_jam table and migrate all songs' artist_id to artist_jam_id instead 3. Change the api so that the song & album class has a array of artist id, instead of a simple integer value.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/koel-koel#476
No description provided.