Quote:
Originally Posted by chaley
Actually, it probably is a few minutes.  |
Show off
For me it'd take longer, but thanks for the hints.
Quote:
|
Look at the new class library.field_metadata, available as db.field_metadata. This a dict, keyed by the attribute name.
|
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.)
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?
Any other types that should be appended or that have defaults that should be overwritten (like the default author "Unknown")?