Alec @uncoy I have come across your posts with respect to DxO no longer supporting certain models/OS versions of Mac. With respect to my posts in this thread it started because some other users experienced problems when upgrading from PL4 to PL5. I had also had the same problem so I did some digging and wrote the posts, one of which included the phrase you quoted!
I have never worried about the database in the past and have never had to but on this particular release… There was nothing in my database that mattered (albeit I managed to recover it anyway) but for others it represented the results of a lot of effort.
In the case of @rsp DxO helped to salvage that investment and I am glad that they helped, if I was being critical I would probably suggest that it should never have happened in the first place but …
I was also under the wrong impression that the database did not hold an up-to-date copy of the editing data and that the DOP was the sole custodian but that was a very wrong assumption. Effectively the database is the prime custodian and PL goes to some lengths to protect the database entry, creating a ‘Virtual Copy’ whenever it is in doubt!
So what have I “discovered” so far
- Changing the Uuid at the end of the DOP does not cause an instant VC.
- Changing the Uuid located just after the ‘ShouldProcess…’ field causes an immediate VC. It is also probable that the file date timestamps are changed by the software I used to change the DOP and that alerted PL to the occurrence of a potential change.
- Changing the keywords in the DOP has no effect, PL5 currently appears to ignore the change and quickly changes the DOP back to the original value.
- Adding a keyword to the DOP and changing the Uuid (from 2 above) will result in a virtual copy with the new keyword.
- The ‘Name’ line in the DOP is not used as a checking mechanism, changing it will not have any impact and PL5 will change it back quickly (as part of a DOP update).
- I did cut and paste the editing from one photo DOP and pasted it into another DOP leaving the top and tail of the “old” DOP intact and managed to get PL5 to accept the new editing (with no VC) but using a preset is a lot easier!!
I would conjecture that a DOP will only be imported into the database if there is no entry in the database already otherwise it will come in as a ‘Virtual Copy’. What plans DxO have for the keywords in the DOP I am not sure but a command that allows for its import would be useful in the event that it is the only data available to a user.
I personally would like more controls to allow virtual copies to be “promoted” to the [M]aster status and the old master either to become a virtual Copy or be replaced entirely.
If you have read any of my posts during PL5 testing you will know that I have concerns about the underlying code. The database structures are incredibly “thin” compared with Lightroom, Photo Supreme etc. and others have commented on this but that only matters if there are any risks of system crashes at critical stages in the database update process or software bugs.
The latter brings us back to the reason for this thread in the first place!? The good news is that securing the database both physically and using the ‘Backup’ option in PL5 can go a long way to reducing the risk of the loss of investment.
Finally we have the question of the metadata itself being maintained in the actual JPEG and DNG and in ‘xmp’ sidecar files for RAW files. I know that there are PL5 users that want to be able to store metadata in sidecar files for JPG and others that want to store that metadata in the RAWs themselves. There are packages that allow for both options and currently PL5 follows the Lightroom line so metadata comes from and goes to the JPEG and DNG and to and from the ‘xmp’ sidecar for RAW files.
Many, many years ago a new release of Zoner damaged the exif data of some of my files, it was fixed quickly but the backup strategy needs to be able to cope with the fact that the data you are backing up may be corrupt and the backup copy is actually the intact copy! My backup strategy uses Beyond Compare which will warn about such occurrences but it is too easy to force an overwrite of the data and for speed I do not use BC in data compare mode, i.e. it uses size and date/timestamps for speed.
@sgospodarenko has recently posted an “annotated” DOP in response to requests from users in various posts.
Hope this helps.