[rkworthy]

Originally Posted by chaley

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

Ok that makes sense I was looking at it from the perspective of duplicated data, and hadn't connected the fact that though there were many forms of author_sort for an author in Books there was only one instance of that author in Authors. I was still under the impression that one author had one author sort and if the sorts were different it was more than one instance of an author.

Originally Posted by chaley

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

This is an area that's unfamiliar for me. I can only find 3 files that reference the meta2 view and they don't seem to provide an interface to it. Could you point me in the right direction to learn more about this? Is db.get_metadata not the best way to retrieve metadata for a book?

Originally Posted by chaley

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.

That's certainly understandable.

Originally Posted by chaley

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

Since I'm only adding it for the built-in fields specifically authors, author_sort, series, publisher, and maybe tags(I haven't approached this area yet), I figure the use case is pretty straightforward. An example case would be like my David Weber example earlier, if I was just sorting by author in the library view I wouldn't be able to tell which ones had Weber, David and which ones had Weber, David J unless I happen to notice the titles weren't alphabetical. If I bulk edit them for something else, let's say publisher, but the author sort field isn't filled then I know something is wonky and can fix it then. Otherwise I would keep going by that erroneous assumption until something else went wrong. It's similar to the colored backgrounds in the metadata-single dialog. It's just a quick visual check to make sure your assumptions are accurate.

The main goal is a quick check to make sure that the metadata agrees when selecting a group of books, which in my mind would be that they match exactly. It would only be for testing if all are identical. If it only showed the ones that matched and forgave any extras then that would lead to more erroneous assumptions. Programmatically I'm saying if there is only one unique item in a set of that particular field then they all match and there is no need to overwrite that field unless the user changes it. I agree that tags would be different, though you could just test for set equality rather than string equality.