While fooling around with a script to add custom metadata, I stumbled upon this behavior:
The script adds custom metadata to a record
I remove the custom metadata fields from DT’s global preferences
Now I run getCustomMetaData in another script on the same record, and the old custom metadata is still there.
So apparently, we have a global list of custom metadata. And every record has its own set, existing independently of the global list? So, that when I remove a meta data field from the global list, it does not get removed from the record(s) where this field is already set?
Is that intentional? If so, what would be the recommended way to remove custom metadata from a record – simply setting the property to an empty record/object/dictionary?
In addition, there’s another kind of weird behavior: The global preferences custom metadata fields get kind of resurrected when the metadata of a record get changed. For example:
Set custom metadata fields A and B on a record
delete both fields from global preferences
set custom metadata field B on the record
voila, the global preferences again contain the custom meta data field A.
Again: is this intentional? I understand that calling addCustomMetaData creates a field if its not there already. But it also seems that these fields never really go away…
It is. E.g. different users could use different setups and still synchronize their databases or exchange their files (as DEVONthink stores the custom metdata data also as extended attributes).
This should work.
Definitions are automatically added if necessary. That way e.g. scripts don’t require that a user has to define certain fields first, the script just works out of the box (like the *Download Bibliographic Data" smart rule script).
I think what bothers me is the mismatch between the UI representation and the API view:
the general preferences show no metadata fields, nor does the UI for the record, but getCustomMetaData returns metadata. Although I think I understand what’s going on there, it seems inconsistent to me.
In my opinion, it should not be possible to remove custom metadata fields from the general preferences (by clicking on the “minus” button at the bottom) as long as a record is using them. Removing them from the general preferences while they’re still in use just gives a wrong impression. And there is the little checkbox besides every item that turns visibility of the field on and off.
I just run xattr -l on a file with custom metadata and it returned this
com.apple.cpl.delete: Y
com.apple.cpl.original: Y
com.apple.cscachefs: L�
�ʖ8���h6���:$�
com.apple.lastuseddate#PS: ��c
com.apple.macl:
com.apple.quarantine: 0082;63049eb4;Photos;
That does not really look like metadata stored in extended attributes to me. Nor does mdls return anything like the DT metadata for this file.
Is this an imported file? In that case a lot of attributes are only added when exporting the file, e.g. Finder comments, Finder tags and extended attributes.
Yes, it is. Background: I’m working on a script to get EXIF/Image Event metadata from images into DT custom metadata. That’s a bit ugly right now because one has to query the Image Events and the EXIF data, and there’s still stuff missing (like title, location coordinates etc.) So, I thought about using mdls instead, which would tell me everything I ever wanted to know about image metadata. But that doesn’t really work with imported images, apparently.
@cgrunenberg I didn’t use Custom Meta Data in a new script for quite some time and just found out that Custom Meta Data now actually is completely removed from a record if it’s value is e.g. set to false. Very nice! This wasn’t the case at the time I wrote the linked script but I don’t remember reading about this change. When did this change?
Sure, I guess I meant: Why didn’t this change appear in the release notes/version history? Maybe it did prior to DEVONthink 3.8, but in the current version history I can’t find something about it. Would be good to know about such changes as it makes things easier
