I'm noticing a worrying tendency in the LMS code over time to assume that GENRE == GENRE->name. This kind of defeats the whole purpose of having a GENRE->namesort field, I think.
I wouldn't agree. The ID isn't something which is stored in the file. All we have is a name. That's where it all starts. IDs change from scan to scan. The name doesn't.
Where do you see that worrying tendency?
A number of year ago, Andy submitted a bug-fix (I've forgotten for which bug) that broke "scan for new" scanning because his fix assumed that GENRE->name equaled GENRE->namesort. Ever since that bugfix, I've had to run LMS using a custom /slim/Schema/Genre.pm to undo his breakage.
Could you please provide a diff of what you've changed? File a bug report and attach the diff.
I'm noticing that Michael just added code that stored genre searches by name rather than by id. I haven't really tested this code yet, but I'm wondering if this is going to again break something for me.
What change? If you saw it in the Advanced Search changes, then there's a simple reason: as I mentioned above IDs can change. Therefore we can't save a search using the ID, but must use the genre name.
I guess what I'm trying to ask of the developer(s) is this: in all cases, isn't the id field in each relational table the "real" identifier?
No, it's not in all cases, because the ID can change. And if we want to survive such a change, then we have to rely on something else.
> Shouldn't we be able to depend on the name field as being
just a label that should be able to be modified on the fly without breaking scanning, searching, etc?
You're not supposed to change values in the database behind the back of LMS' own logic. When you start to tinker in the guts of the application, then you must be ready to deal with the unexpected.
But going back to the subject of your posting: "GENRE Problems". Multiple problems? Where are they? All you said was that you saw a tendency. But I really didn't get what you consider broken recently.
-- Michael _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
