[chaley]

Originally Posted by kiwidude

I'm not sure I understand all your persistence reasons, as surely similar justification for not using a custom column to store exemptions applies to storing groups? Take for instance the example of (1,2) and (1,3) being found. We display (1,2). Now if the user goes "next group" without doing anything, we will want to display (1,3). If the user merges book 2 into book 1 before going next group, we will still want to display (1,3). However if they merge book 1 into book 2, then the (1,3) 2nd group is invalidated. If that information has been persisted into a custom column, the plugin potentially will be doing a lot of repeated querying to find a next group, validate all the ids, clearing the persisted column if group is not valid, move to next group etc. I would have thought that might be a little easier to do when not persisted in the database?

I assume that one stores the group ID in the custom column, not pair relationships. I also assume that if one book is merged into another, then one of those two books is deleted.

If both of these assumptions are true, then your examples don't create a problem. In the first case (2 -> 1), book 1 will still have all its groups, so next_group will show (1,3). If 1 is merged into 2, then 1 no longer exists and next_group will show only book 3.

For point (3) of viewing groups a book is in, you can still do that. You would always have to rely on some kind of in-memory mapping the plugin kept of groups and their members. So I don't see that reason as a differentiator - in fact it could well be easier just using in-memory results because you don't have to re-read all the custom group ids and re-build the mappings as you would if relying on the persisted values?

I think we must have a different mental model of what is written in the custom column. I am assuming that the CC is a multiple column that is filled in with the group ID of each group the book is a member of. I don't see why I need to rebuild anything. If I search for group 34 (which I can do from the tag browser), I get all the books in group 34. I can resolve duplicates manually by removing a book from a group. The plugin could help with that, if it knows what group I am working on.

I also assume that telling the plugin that two books are not duplicates does not rerun the partitioning algorithm. The new non-dup info would be used next time I run it.

I think the point (2) of doing the resolving across Calibre sessions is absolutely valid, though I think it comes down to the workflow again and how long it takes to run the duplicate search. For me I either resolve the pair in some way or else it will come up again the next time I run the search.

I agree

Whether I do that now or the next time I open Calibre (and trigger another search) to me doesn't matter, that pair still needs to be resolved in some way.

I can easily imagine running the check, scanning the results over time, and merging/fixing any problems without doing any other resolution. Next time I run the check (which could be in months), I see the same results. If I get annoyed enough, I would go to the trouble of indicating that books in a group are not in fact duplicates.

It is a good point about using a custom column for transitive based sorting. Though unless you forced that column visible on the view one stray click by the user and the sorting is lost, they would like have to do "next group, previous group" to get it restored. However at least for the first cut since transitive groups are not being displayed I think I can again avoid this issue for now anyways.

I assumed the column was visible.