View Single Post
Old 03-12-2011, 05:37 AM   #13
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 kiwidude View Post
If I was to use this approach instead of set_all_metadata:
Code:
        meta = db.metadata_for_field(key)
        mi.set_user_metadata(key, meta)
        mi.set(key, val=whatever_it_is, extra=whatever_it_is)
For just the custom series column(s) the user manipulates in the dialog, is that the appropriate solution for those empty book rows? As I said above my concern is to make sure that the Metadata object is valid to be saved with set_metadata, and if I only "partially fill it" by setting just one or two series columns on it then does that have no detrimental effect on any other non-relevant custom columns that I will not be touching?
Yes, it is perfectly valid not to supply columns. When you add a book with the GUI, no columns are supplied. Missing columns are set to their default value.
Quote:
Your point about not trusting the source of the custom column is a very interesting one, I appreciate the warning. However what is the appropriate approach to overwrite the column in that instance, because the code you showed me just ignores it. Certainly in my case now that would be undesirable - the user would be left with a book that they could not set a value for in that column because in it's original source in some other database the column had a different datatype?
The situation that the code I quoted is facing is that it can be asked to store type X into a column with type Y. It can do one of 3 things:
  • Stuff the wrongly-typed data into the field. May not work at all, and if it does, it is likely to produce odd results.
  • Convert the 'wrong type' value into 'right type' value, then store it. This can be complicated, and there is no guarantee that the user will agree with the conversion.
  • Ignore it, leaving the existing data alone and doing nothing with the new data. This is the choice set_metadata makes.
In your case, it seems that you have already determined that a) the column exists in the db, and b) the column is typed as series. If so, you won't have the above problem. However, if the user can give you (for example) a Yes/No column key, then you must be more careful. My understanding is that you are not using metadata from another source, but instead are creating metadata based on the currently-attached library. If I am correct, then the problem devolves to one of input sanitizing, ensuring that what the user is asking you to do makes sense.

Final case: you construct a Metadata instance for a book that is already in the DB without using get_metadata. In this case, standard metadata will be replaced with 'non-False' data from the mi object. Custom columns will be replaced with values from the mi object if a) they exist in the mi object, and b) they have the same type.

FYI: I intend to add a parameter to set_metadata to override the 'non-False' check, because as is, set_metadata cannot set a standard metadata column to nothing. For example, you cannot set the tags to empty or empty the ISBN.
chaley is offline   Reply With Quote