I am collaborating on a script which imports DT3 records to a MongoDB database.
The new MongoDB database is giving errors when there is a dot in the name of a custom metadata field.
Frankly it was probably not a good idea for me to use such a metadata field name in the first place and it really is not important any more - so I deleted the metadata field from my database.
But surprisingly the error still persisted.
Examining the data further with Script Debugger, I see that the deleted field and its data is still there- but the field name has a pipe added before and after the name.
At first I thought this was a bug but I am wondering if it is instead a feature.
Can you confirm that this is intentional as an alert to avoid that metadata field - but so the data still exists and can thus be recovered if I choose to reactivate the the field in the future?
Script Debugger automatically adds pipes if necessary. But I’m not sure whether in your case DEVONthink also added pipes. Please check if the meta data identifier in DEVONthink’s preferences also has pipes.
Yes, removing an entry from the preferences only removes it from the UI. Don’t know whether it’s the only reason but it’s done for cases where users share a database (if the actual data were deleted from the records then it would be deleted for all users).
It doesn’t know. Script Debugger adds pipes if a term isn‘t allowed as a record key
(But it doesn’t add pipes in all cases where they would be necessary. Not sure about plain AppleScript, but e.g. in AppleScriptObjC methods it doesn’t add pipes to error:)
Not sure I understand. DEVONthink does nothing like that, I think.
If you didn’t delete a given custom meta data from a record but only removed it’s entry in DEVONthink’s preferences then you can always get the data from the record. It’s just not accessible thru the UI anymore.
In your case where a identifier that contains a dot is resulting in an error while adding to a MongoDB database you’ll want to delete this identifier’s custom meta data from all records that you’d like to add to the MongoDB database.
Yes I may do that - That was actually my Plan A. Then I figured a more generalized solution might be nice in case I accidentally added an invalid identifier in the future or in case I eventually share this project with others and they have similar issues in their database.