View Single Post
Old 08-02-2011, 08:20 AM   #8
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,465
Karma: 8025600
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
@DMee: calibre's database is (currently) a SQLite DB with lots of n-ary normalized tables to handle multiple items such as tags, authors, etc. I say "currently" because Kovid is changing the database back end.

There are many triggers and other data integrity operations that must be performed when touching certain fields. For example, if you change an author or a title, you must also change the file system structure. Changing almost anything requires placing an entry onto the metadata backup queue. You mentioned title and author sort (in the books table), but there is also the author sort in the authors table to deal with. If you change any item in one of the normalized tables, then you must do duplicate checks and reconstruct the connection table(s) appropriately. The list goes on.

Unless you alter the metadata.opf backup, there is no rebuild of the database available to you.

Also note that there is (currently) no concurrency control. It would be up to you to ensure that calibre and your DB application are not both running at the same time.

My conclusion: you could make this work, but the risk of nuking at least the book you are working on is quite high.
chaley is offline   Reply With Quote