[chaley]

Originally Posted by kiwidude

Thanks Charles.

Just one last point on that invalid column thing as you kind of freaked me a bit with it. Say you have two Calibre databases. In database A you defined a #myseries column of type Series. And in Database B you defined a #myseries column of type Yes/No. Then I copy a book out of Database B into Database A. Funky I know, but if people download/import books off the internet which have opf files it could happen.

I think this can easily happen, especially when people are using multiple libraries.

So in Database A, for that particular book that has just been imported, when I read that book using get_metadata and look at the value in the #myseries column, what am I likely to see? If I try to set a value into that #myseries column for that book, will it be using my database A definition of the column being a series field, or a book source based definition from Database B of it being a Yes/No field?

Duplicate detection plays a role here. Assuming no duplicate -- the import creates a new book. In this case, an mi object returned by get_metadata in db A will have both #myseries and #myseries(extra) == None. If the book is a duplicate and is merged, then the values in mi will be what they were before the import.

The definition of a column is always dependent on the database the column lives in. There is no circumstance where the definition will change because of an import. If there is a key/type match, set_metadata will change the value and extra in db A to what came from db B, otherwise it will set nothing. It will never change anything else, including the optional description information in the 'display' field.

Because of this rule, there are circumstances where you might be holding an mi structure that does not correspond to what is in the DB. Your example is one; the mi structure from db B (presumably made from an OPF) will have different information in it from what would be returned by get_metadata in db A after an import. It is therefore not safe to assume that after a dbA.set_metadata(dbB.some_mi), dbA contains a copy of the information in dbB.some_mi. The information can vary because of custom column type/key mismatches, 'false' values in some_mi (the tags issue), or even subtle things like tag id order. If if is important that you are using correct information after a call to set_metadata, you should do a get_metadata immediately after.