@joanna @sgospodarenko Well I wouldn’t trust me to “design” the database, the ‘ItemsKeywords’ structure listing was just above the above comment in my post but I still incorrectly suggested that the new fields I was suggesting should be added to the ‘Keywords’ structure!?
The new fields belong in the individual “incarnation” of each keyword used, i.e. the new fields would belong in the ‘ItemsKeywords’ structure not the ‘Keywords’ structure if such a scheme was implemented.
@Joanna I am aware of your knowledge of the guidelines but the “guidelines” that I “follow” are based on empirical study, i.e. whether what I am doing and the response to my actions, by software, is typical or atypical!
Entering the hierarchy using the top-down syntax of animal|mammal|bear is accepted by every piece of software that I have used and, where the software actually “understands” hierarchical keywords it is used as it should be (more or less!). The bottom up syntax bear>mammal>animal or animal<mammal<bear seems to be acceptable to a number of packages but I have not tested them all with this syntax.
I do not for one moment believe that the style of data entry to PL5 has one iota of impact on the product or the problems that I am writing about and if PL5 is wrong it is in “good” company because the rest do it the same way (rules or no rules).
However, continuing our discussion in this topic is unfair on @John7 who will be receiving alerts every time a new post is made so I propose to start a new “bug” topic with respect to the changes made to PL5.2.0 keyword handling which will include the latest version of the spreadsheet (almost complete).
What I did discover is that there are 3 options available for formatting hierarchical metadata in IMatch and one of those exactly matches the new format being used by PL5 but at least IMatch gives you options and doesn’t change the product between two intermediate releases with zero explanation for the rationale and zero documentation, in fact IMatch’s documentation is so complete that I am likely to miss something significant because of the shear amount of detail on offer!
I will keep you informed when the new topic is posted.
@Photoman43 I am concerned by your post in particular the statement that
and
Please be more specific in both cases since I have tested the issues extensively and written about them, including a procedure that should enable you to move from one system to another, a directory at a time without experiencing problems, namely Synchronise PhotoLab - #26 by BHAYT .
Related problems are also discussed in What is the best way to move a folder of photos with their respective *.DOP and *.XMP files? - #15 by BHAYT
At the time I wrote the procedure it was just theoretical but I have subsequently tested it and it worked for me on Win 10)! Indeed if you are careful you should be able to take the images back and forth between two or more systems as many times as you want!
In order to see if you are “losing” any data you could conduct the following test (incidentally you don’t say what type of images you are using nor what versions of DxPL you are transferring between)!
-
Create a new Directory, e.g. TEMP, and copy a few “typical” images to that directory, on your laptop.
-
Apply edits that you believe you are losing in the transfer to any or all of the images.
-
Any ‘Rating’, ‘Rotation’. ‘Keyword’ changes you make must be “flushed” back to the image xmp metadata, embedded for JPG, TIFF or DNG, or xmp sidecar for RAW by e.g. ‘File’/‘Metadata’/‘Write to image’.
-
Copy the directory (contents) from one location to another on the laptop e.g. from TEMP to TEMP-NEW, where TEMP-NEW is “unknown” to DxPL.
-
Discover the directory in DxPL by opening it and all the edits, metadata etc. should be intact! If they are not then please re-post here.
-
If it works then use the procedure to move TEMP to your other machine and check.
-
Feel free to move them back to the laptop using the same procedure.
-
I have run into problems with deleted images throwing up multiple Virtual Copies for images that I have just deleted from the directory! This only seems to occur when the directory I have made the deletions to is actually open when I transfer the “same” data back into the directory and is definitely a “bug”.
NEVER copy files from one machine to another into a directory that has the same name and same images as one on the target system, otherwise Virtual Copies will be created because the incoming DOP Uuid will not match the Uuid on the receiving system, at which point DxPL leaves the existing database copy as the [M]aster and imports (probably the later updates) as Virtual Copy [1]! Although I and others have asked for an automatic command to elevate [1] to be the [M]aster who knows if that will ever arrive.
I have a procedure to enable it to be done but it is very laborious, i.e. it is way better to avoid the problem entirely. If it does happen you are better to show all the Virtual copies via the thumbnails and delete them (the VC’s only) and work out what went wrong with the “move” procedure and execute it again!
As far as I know this Virtual Copy issue is the only problem moving data between systems, excluding any “bugs” you may have turned up!? You should not be losing data unless it is metadata which you have not “flushed” back from the laptop DxPL database to the image file prior to transporting it (except for the DxO ‘Tag’ field where I believe there is still a bug, i.e. this still resides in a PL5 DOP and PL5 should read it back from the DOP but it isn’t doing that!!)