Modified Date on Titles.

[Quoth]

I updated two books this morning, but next time I opened Calibre in the afternoon I didn't see them at the top when I clicked on "Modified" Column.

It was because they now show as oldest of 50 books modified TODAY and many of those titles not touched for ages!

What has happened?

[itimpi]

I have seen this if you accidentally change the case of a tag. All books using that tag will get their modified date updated.

[Quoth]

I changed "Short story" to "short story" on tag on one book. I see all 48 extra ones have "short story" as one of the tags. This seems like strange behaviour. Would it change the "short story" tag to novella on ALL books if I edited one book/title?
Also it's only one of the tags on those books.

Is there some logic to this I don't understand? If I edit a Series name or a Collection name it doesn't change all the books with the original match unless I select all the matching books and do Edit Meta data in Bulk.

I don't like this behaviour. Your explanation certainly seems correct.

[DaltonST]

In SQLite, you can indicate that a column should be case insensitive when you create the table by specifying collate nocase in the column definition.

Tags have always been 'collate nocase' in Calibre.


DaltonST

[DNSB]

Originally Posted by Quoth

I changed "Short story" to "short story" on tag on one book. I see all 48 extra ones have "short story" as one of the tags. This seems like strange behaviour. Would it change the "short story" tag to novella on ALL books if I edited one book/title?
Also it's only one of the tags on those books.

Tags are not tied to a book. And yes, if you modify a tag, the modified tag will show on all books that use that tag and the modified date for all books using that tag will change.

So if you edited short story to novella as a tag on one book, it would edit the tag for all books using that tag. Adding a new tag (novella) and deleting the old tag (short story) from the book is the procedure I follow.

[Quoth]

Right, now I know. Delete and add, don't edit.

Thanks, DNSB

[chaley]

Originally Posted by Quoth

Right, now I know. Delete and add, don't edit.

Thanks, DNSB

If I am following the thread correctly, that won't do what you want.

The "problem" is that as DaltonST points out, there can be at most one instance of a tag with a given spelling, ignoring case. If you delete the tag from a book then add it with a new case then if that tag exists on other books with different case then the tag will also change its case. You have only 2 choices:

• use the existing tag (with its letter case) so nothing changes other than adding the tag to the book.
• use the same spelling with different letter case, in which case the tag will change on all books with that tag.

To do what it seems you want then you must change its spelling.

I think there is zero chance that this behavior will change.

[davidfor]

Originally Posted by chaley

If I am following the thread correctly, that won't do what you want.

The "problem" is that as DaltonST points out, there can be at most one instance of a tag with a given spelling, ignoring case. If you delete the tag from a book then add it with a new case then if that tag exists on other books with different case then the tag will also change its case. You have only 2 choices:

• use the existing tag (with its letter case) so nothing changes other than adding the tag to the book.
• use the same spelling with different letter case, in which case the tag will change on all books with that tag.

To do what it seems you want then you must change its spelling.

I think there is zero chance that this behavior will change.

This is one of the few points I strongly disagree with Kovid about calibre behaviour. That and updating the modified timestamp for all books when adding or removing a custom column. Both go against everything I've ever done with database migrations and updating. I have spent to much time turning off the automatic updating while modifying the database schema to agree with this.

@Quoth: There is option or tweak that related to this. If you set it, it is a little harder to accidentally change the case of a tag in the metadata editor. Unfortunately, I can't quickly see what it is. I think I have it set at home, so I'd have to check there.

[BetterRed]

There are some tools in the JobSpy PI that wrangle the Modified Date.



And there's a Last Modified plugin from capink

That's as much as I know about them.

When I realised how calibre's Modified Date was used I decided to ignore its existence. In one of my libraries I have a Last Changed Date column, I edit metadata in the book list which means its easy to tab into that column and hit '=' when I deem it worthwhile.

BR

[ownedbycats]

Originally Posted by BetterRed

And there's a Last Modified plugin from capink

Personally, I use this. It's very customizable and you can temporarily disable it when needed (e.g. making a change to every book in the library).

[Quoth]

Ah, so deletion & adding will STILL modify ALL the books with case-sensitive string match for the tag. Strange behaviour!

[Quoth]

Originally Posted by BetterRed

And there's a Last Modified plugin from capink

I installed "Last Modified", but I can't see how I should configure it to ignore tag edits.

Also what if I wanted the the same tag text in two or more variations of case? I don't understand why the tag editing behaves like this. No other column does?

[chaley]

Originally Posted by Quoth

Also what if I wanted the the same tag text in two or more variations of case?

You can't.

I don't understand why the tag editing behaves like this. No other column does?

All many-to-(one/many) calibre columns have this behavior. Examples: authors, series, tags, publisher, custom tags-like columns, custom text shown in tag browser, custom series columns, and custom enumerations. Custom composite columns do not share this behavior because their value is not stored in the database.

[theducks]

Originally Posted by Quoth

Ah, so deletion & adding will STILL modify ALL the books with case-sensitive string match for the tag. Strange behaviour!

It is a Relational Database, so it is not strange.

When you add a new tag, its name goes into the 'Tags' table and it is assigned an index-number. To make data management/searching easy, the entry is normalized (case insensitive).

All the books refer to that Index-Number.
FWIW almost all other lookup equipped fields do similar (just no case insensitivity).

[Quoth]

I spent 20+ years designing & implementing Relational databases. The difference in how tags work vs editing a Series name or an Author name isn't inherent to using SQL, it's a design decision. It could create a new entry in the tag table rather than change the entry, that naturally all the titles use. I've not seen this behaviour on other columns. There may be sound logic to it. I don't really use tags and thus I haven't thought about it.

Editing an Author or Series only changes the title being edited, though perhaps I've never ONLY edited the case and maybe that behaves the same.