[chaley]

Originally Posted by rkworthy

Why does the db.author_sort() lookup the author sort in the books table rather than the authors table and authors link table?

Because author_sort can be (and is) different from the concatenation of authors' sort strings.

As far as I can tell the only places db.author_sort() is used are in the initialization of the metadata_single dialog and in db.get_metadata(), which also uses authors_with_sort_strings().

Most of the accesses of author_sort are done through the meta2 view. There is seldom a need to use db.author_sort.

I'm probably missing something, but it looks like a one way street, if authors->author_sort is updated using set_sort_field_for_author then books is also updated with the new author_sort, but if books->author_sort is updated with set_author_sort then just books is updated.

Setting a book's author sort does not change the sort strings for the author(s), because there may be no discernible relation between the two. Nothing stops me from setting a book's author_sort to whatever I want.

The choice to update the books when the sort string for an author is changed was not made lightly, and it could be argued that it was wrong. In the end, I decided that if you are playing with an author's sort, then you *probably* want to change the author's books. No one has complained yet. It is arguably better to change only the books where the value of the author_sort equals the value of the previous author's sort, but I didn't do this because it hinders repair when the author sort values get wildly out of sync. It would also be slow and possibly mysterious.

I'm specifically working on the Ticket #847 and noticed that when I built author_sort using db.get_metadata().author_sort_map it came out differently than db.get_metadata().author_sort. After looking around I saw it was because they are drawing from two different tables, and in my particular case those tables had different data. For example my books table has "Oath of Swords" author_sort listed as Weber, David J. but looking up that book through book_authors_link and then to authors it shows as Weber, David.

This is precisely the situation that must be accounted for. For whatever reason, accident or intentional, the book has a different value than the author.

As regards the enhancement request, the custom columns already do much of what the ticket is asking for, at least for fields with single values (although I seem to have forgotten series, which is probably a bug). Multi-value (is_multiple) fields are more complicated: what does equals mean, exactly? The authors field is even more complicated, because order matters, which isn't the case with tags.

It isn't at all clear to me what should be displayed for is_multiple fields. Should it display only if all are identical? Should it display the ones that are identical (which would open up some interesting UI issues)? For authors, should it respect order (I think yes)?

I'm not really sure how they got out of sink, but it would make sense that if the author_sort column was necessary in both tables that there would only be one function for changing both tables rather than ones for updating one table or the other.

No. Remember that it is intentional that a user can set the author_sort for a book to be different from the 'natural' string, which is built from the authors' sort strings. There are reasons for people to do this, especially in edited volumes, multi-author books, when devices expect strange author values (although plugboards ameliorate this one), or simply personal preference.

To summarize that wall of ramble.
[*]Why is there author_sort in the books table when author is looked up through the link table?

Because they contain different information. The book table author_sort is used all over the place through its inclusion in the meta2 view.

The link table question is different. All is_multiple or single-field tag-like information is normalized in the database, which is good practice and generally useful.

[*]Why are there functions for updating one table but not both?

There are functions for updating both. If you are asking about the side effect of setting the sort field for an author, I discussed that above.

[*]Why does get_metadata() draw from both rather than just building author_sort from the author_sort_map?

Because as noted above, they can be (and are) different.

Including the author_sort_map isn't strictly necessary because it doesn't appear in the user-visible metadata for a book. It is included for completeness, making it easier to compute on authors without needing to split the authors string and so that the OPF contains all the information for a book.

Final note: as itimpi said, there are some legacy aspects involved. I added the sort string for authors in the 0.7 releases (don't remember exactly when), something that permitted fixing some bugs but also made explicit the difference between the author_sort and authors' sort strings. If I were designing it today, I would need to reflect on whether the two values are strictly necessary. I think yes, for the same reason that there is title and title_sort. Second question: does author_sort need to be editable? Good question. I think yes, because users have all sorts of needs that we can't anticipate. That raises the title/title_sort functionality discrepancy; title_sort cannot be changed by the user. I have wondered about that decision, because I have had instances where I wanted to manually edit title_sort.