Quote:
Originally Posted by Starson17
It looks like that includes non-custom keys as well. Correct? Will "for key in db.field_metadata:" loop through all fields, including, e.g. title and authors? If I'm going back into the code again it might make sense to make a single loop for all metadata, instead of keeping the current non-custom tests and adding a loop for the 'is_custom' fields. That way, if the old fields are ever renamed or a new non-custom is added, it will still be merged (default of: if it doesn't exist in the destination, but does exist in a source, merge it in.)
|
Yes, it has all the fields, or at least is supposed to. I wondered whether you could unify the processing. I found in the search code that I could.
If you are going to play with standard fields, then you will want to know about field_metadata[key]['rec_index']. That field is the index into the _data record. You would use db.get(id, rec_index, row_is_id=True) (found in library.caches.py) to get the value for that field for a given db_id. Don't use db.set function in caches.py, because the data won't be written to the DB.
Quote:
|
Can you think of any of your field types that need special handling? I've forgotten all of the different types, but if you have one for text, like comments, should a src be appended to the dest or ignored?
|
This is really a requirements issue. Are tags (text, is_multiple=True) merged, or do they overwrite? Are comments merged, or is one overwritten? What happens with series indices? The equivalent custom fields should have the same processing.
My guess is that text (non-tag, is_multiple=False), bool, int, float, and date columns should overwrite. Make sense to you?
Quote:
|
Any other types that should be appended or that have defaults that should be overwritten (like the default author "Unknown")?
|
No. No type has a required value, and all can be set to None.