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.  The namesort field was added
so that GENRE->name(s) could be modified, post scan, to any desirable
text without breaking sorting and without breaking pointers to the
original genres scanned.

So, for instance, having been a music history major at university, I tag
all my classical music according to musical historical genres, and in a
way that they'll sort chronologically:  e.g.

a_Medieval
b_Renaissance
c_Early_Baroque

..etc.

After a LMS scan, my PostScan plugin automatically runs a modify query
on the GENREs table and modifies GENRE->name records so they read:

Medieval
Renaissance
Early Baroque

..etc.

Because the GENRE->namesort records haven't been touched, the
chronological sorting of genres still works, even though the alpha
sorting of GENRE->names no longer matches.

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.

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.

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?  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?


------------------------------------------------------------------------
gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115
View this thread: http://forums.slimdevices.com/showthread.php?t=102190

_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to