I beg to difer . The sister table doesn't contain any duplicate information (in db parlance, it is normalized). The only thing it has is the split artist name (which is not the same as the artist name) and a relation back to the songs table (the songs_id). Note that for briefness sake I didn't note all the fields that are present in the songs table that would not be present in the sister table. There are a number of other similar sister tables that already exist in the MM database (such as 'AddSongInfo' or 'Played'). To the extent possible, I agree with you that one should not be adding tables to the MM database. In this case, it would be worth it. But...Pablo wrote:I'm of the philosophy that having duplicate information is a receipt for disaster , so I would try to avoid sister tables at all costs. In any case, your idea cannot currently be implemented through scripting (tracks can be added to the Library and updated independently of the scripting system).sadao wrote:
I think that the only way to handle this so that it will work quickly enough is by having a sister table to the songs table (i'm saying this cuz i'm dealing with about 30K tracks).
... this is all moot anyway. Maybe the Devs will want to implement this. I guess the ease with which this can be implemented depends on whether changes to the songs table are always carried out by the same method/function (in which case it's easy to add the maintenance code for the sister table).Pablo wrote:In any case, your idea cannot currently be implemented through scripting (tracks can be added to the Library and updated independently of the scripting system).
Pablo wrote: If you want to learn about the scripting model (especially as it relates to creation of nodes), I would suggest you to look at the sample lyricist node script and other scripts created by jmaver and octopod first. Magic nodes is already over 1200 lines and may not be the easiest one to read .
I'll do that then.