Quote:
Originally Posted by kovidgoyal
Umm calibre's "performance problems" have nothing to do with the database format. calibre currently uses an sqlite database to store metadata, as well as the relative path to the directory for each book, storing absolute paths would actually increase the memory footprint.
Incidentally the bottleneck when importing books is reading metadata from them, especially for PDF files.
|
Well, copying 10GB of data is a pretty slow operation. I would wager that's a much worse bottleneck than reading the PDF metadata, although I haven't tested it.
Quote:
|
As for the robustness issues, you're looking at it from the perspective of a single user. Sure *you* may be organized enough and careful enough not to lose track of files lying around in obscure corners of your filesystem. Most people aren't.
|
As long as calibre is open, you can actually detect changes to any of its referenced files immediately by using o/s specific APIs to watch the filesystem. In any case I don't think this is a very big problem, as long as you can tell them what happened (i.e. the file must have been deleted manually) then I think it's very minor. Besides, since it's *already* using an sqlite database to store the paths, the absolute path thing could simply be an option specified at library creation time. You could put it in an "advanced" tab and put (Recommended) by the default option of allowing calibre to copy.
I'm just saying, there are solutions to all the problems you mention, as long as you're willing to think about the problem instead of just writing it off. It can even be made so that everyone who loves the current system would still be able to use the current system by default, it seems like a win-win. I don't get it.