|
I think I might have figured out what this discussion is about.
First, let's establish some vocabulary:
- Item: some book metadata that appears in a column. A tag is an item. So is a series name, or the value of a text custom column.
- Built-in category (BC): a column (field) that appears in the tag browser. Built-in categories contain items.
- User category (UC): a pseudo-column appearing in the tag browser. User categories are not related columns in the library view.
Using these terms:
BCs contain by-value references to items, which as noted above are actual metadata values in books. BCs are rebuilt when metadata changes. There is no persistent representation of BCs other than the metadata in the books.
UCs contain by-name references to items, in the form (item value, item BC). These references are stored separately, because they cannot be re-created from information in books.
I think you have discovered that the references in the UC remain after deleting items. If you re-create the item, then it will reappear in the UC because the reference is still valid. The by-name reference in the UC to the now-gone item remains, because the reference has no connection to operations on the item. You can test this by opening manage categories after deleting an item. The UC will show the item name along with the comment (Not in any book).
References cannot be deleted when the item is not shown in a BC. Consider restrictions: it is possible for items not to be shown, but the references to them must not be deleted. It is problematic whether renaming items should modify the references. Consider swapping names for items. The operation is A-> TEMP, B->A, TEMP->B. What should happen to the references during this operation? Similar problems arise when renaming items in one book but not another and with renaming hierarchical items; it is not clear what should happen to the reference. Currently calibre does nothing, leaving it to the user to decide what to do (if anything).
References to missing items could be purged at startup or shutdown (startup is easier), although I am not sure that doing so would be the right thing to do. The problem is (again) performance. Get_categories must be called to build the necessary maps, which takes measurable time for huge libraries. It might be possible to detect the initial get_categories done during GUI startup, which would avoid the penalty.
|