View Single Post
Old 12-05-2010, 07:08 AM   #9
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: 11,741
Karma: 6997045
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by hakan42 View Post
I think I saw somewhere in the code (aaah, in database2.py) how you update schemas. If you don't mind, I would add a remote_id column. This should minimize the impact on other code...
Another option that avoids a schema upgrade is to add a hidden custom column where you store the ID. There might be some programmatic interfaces to be added to make this convenient (add the col, set it hidden, and have the tag browser ignore it). Perhaps a better approach is to create a non-displayed text column type or to add a flag tells the GUI to ignore the column, which would have the advantage that any number of the columns can be added. One concern is that this 'remote_id' column is just the tip of the iceberg, which using a general solution would avoid.

If you add a column to the books table, you also should add the get_ and set_ methods to database2. You might also want to think about whether the column is multi-valued.

Finally, think about how this field will appear in the EPUB if the metadata in the book is updated. I don't know how to connect the field with OPF generation, but that is probably what you would want to do.
chaley is offline   Reply With Quote