mirror of
https://github.com/koel/koel.git
synced 2026-04-26 09:15:59 +03:00
[GH-ISSUE #665] Compilation state #476
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#476
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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_compilationcolumn inAlbumstable 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_idmapping to, say, "Queen" but with ais_compilationflag set to zero/one. As soon as one of the song with this album referred to another artist, theis_compilationflag was set to one.Currently, if I understand correctly, instead of changing the flag, you change the
artist_idto various artist, and check for compilation by the conditionartist_id == VariousArtistID, right ?If so, how do you link the album with the "main" artist, since the album's
artist_idis 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_idinstead (so instead of a singleartist_idcolumn, maybe rename to aartist_jam_idand add anartist_jamtable with column (idnot 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 ?
@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 ;)
@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_idcolumn in thesongstable.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 theartist_idcolumn insongs.Yet, what do you think about this change (if ok, I'll make a PR for it) ?