Quote:
Originally Posted by q345
One of the possible solutions might be (obviously) to duplicate metadata by keeping all tags/info of a given instance of e-book in a separate small file in the Calibre directory where the e-book (all formats of it) itself is kept, IN ADDITION to metadata.db file itself. In case metadata.db file got corrupted, restoration will be a simple process of scanning the Calibre directory tree, reading all those small metadata files each of them is related to a single e-book only ( to be precise to all the formats of a single e-book) and rebuilding a "main" metadata.db file.
|
This is a good idea that I have been thinking about that for some time now. The file would be an OPF, and calibre already knows how to make them. It wouldn't be hard to write them into the calibre library along side the book formats.
The interesting part is maintaining them. If they are kept up-to-date, then performance of some operations could become unacceptable. For example, if setting a tag on 100 books requires generation of 100 files, performance would go from under a second to many seconds. My guess is no.
One alternative I have considered is a background task that trawls for changed books and writes the file. This would eliminate the performance penalty, but comes at the cost of some complexity and the possibility of the files being out of sync. For example, if I change 1000 tags and then quit Calibre, the OPF files wouldn't match the database. Calibre could delay exit, but then ...
Rebuilding the DB from this backup also isn't trivial. One problem is that the database IDs calibre uses would change, possibly breaking an association with books on devices. The new caching could make this problem go away, and perhaps SQLite permits setting the ID (like MySQL does). Another problem is that at the moment, the OPF does not contain all the metadata, in particular the custom columns. Work is underway to fix this, but it isn't done yet.
All of this is on my list to ask Kovid about once the 0.7 beta is released, custom column metadata is stored, and device collections support custom columns. However, you just asked him, so I might find out the answer early.
