Yes Bryan. I am fully aware that the master can be written to. That is why I wrote “for me…”. In my early days of digital photography I used to use photoshop essentials and soon found out if I wish to edit an image that had already been edited. It was very hard to get back to where I wanted. That is why I believe that the original image (the camera image) should never be written to regardless.
Like you I started with OP9 and never started to use virtual copies until PL4. As far as my images are concerned prior to PL4 they should not be written to if DxO is correct in stating they are not touched.
As far as my posting is concerned, I was replying to @saint-112’s posting immediately above mine. This he obviously didn’t realise and came back with an angry comment thinking I hadn’t studied the whole posting which I had and tried to repeat his problems but could not do so in Windows 11.
@Prem Thank you for the update and @saint-112’s scheme also achieves the same. The difference with the revised scheme that DxO brought in for whatever reason is that it actually creates more work to maintain the “protected” copy plus it must never ever be deleted unless you want to lose the image data.
With the old scheme that would happen only when there was one copy left a rather obvious situation for users surely! With the [M]aster scheme you could have 20 VCs and pick the [M]aster and the message makes it clear that you are going to lose the image but …
Personally I don’t like either scheme!
The removal of edits should be independent of the removal of data.
When there is a “shorthand” in operation it is too risky, someone in DxO thought it was easier to do everything with a single operation and possibly more convenient for the user but I don’t think so, does my opinion count, do I have any right to complain about such coding, well if I don’t after 36 years helping customers build and support 24/7 mainframe database systems then I guess I never will!
That’s the way, I prefer to work too (and labeling with M) – and for even more consistency maybe to start the first VC with number 2 …
But what I really would like to be able too is to rename the VCs (= add a something to the name), so to signal by the naming, what was done with the VC. – Isn’t that possible in the MAC version?
→ ‘Outside of DxO’s world’ I’ve been doing so all the time and it’s simple to keep track by the naming convention.
And yes, I’ve been experimenting a bit with the order from PL2 vs PL6.
Carrying over a file with two VCs shown as “1 + 2 + 3” turns them into “M + 1 + 2” (also in Compare with …), while keeping the order. The exported jpg-files of course keep their filenames, they got in PL2.
What is not kept is the relation from the ‘source file’ to it’s output – btw the same thing when copying within PL6 from one folder to another.
To delete a complete file, I don’t mind to mark up (1 + 2 + 3) or just the master (M). But I’m not sure, what happens with projects. Up til now I don’t use them like I did in old LR 5.7, where I could sort the file’s order and such …
When you select the master only and choose Rename Image… you get a dialog box where you can type the new name. In the film strip only the master’s name is changed. The file itself has also the new name as well as the sidecar file.
When you select a VC only and choose Rename Image… you get the same dialog box. In the film strip only the VC’s name is changed. The file name is unchanged.
When you select the master and a VC and choose Rename Image… you get a different dialog box. In the film strip both images’ name arre changed. The file itself also has the new name as well as the sidecar file.
So you need to shift to a Mac or wait until the feature is implemented in the Win version.
Nick
@Wolfgang Every copy, including the [M]aster gets an entry in the ‘Items’ structure in the DxPL database and they ALL point to a single entry in the ‘Sources’ structure, which has one entry for every image that has been (“imported”) “discovered”.
So if you have never made a VC then you will have one entry in ‘Items’ pointing to one entry in ‘Sources’.
With 6 VCs [1] … [6] created in PL6 you will have 7 ‘Items’ pointing to ‘Sources’ entry, i.e. [M] + [1] … [6] pointing to arguably the real “Master”, i.e. the ‘Sources’ entry!
NO copy numbers exist in the database or the DOP, it is purely “positional” in both cases. In the database it is done via the “position” of the key entry ('SourceId) in idx_Items_Sourceid, an index on ‘Items’, nothing more and nothing less, or so I believe.
idx_Items_Sourceid is an index on the ‘Items’ Table where each entry in ‘Items’ uses the ‘SourceId’ as a pointer to access the data of the entry in ‘Sources’
So if we import (discover) the first ever image it will have an entry in ‘Sources’ with (Source)‘Id’ =1 and an ‘Items’ entry with an (Item)‘Id’ = 1, both 1 because they are the first entries in the respective Tables, i.e. in ‘Sources’ and ‘Items’.
But as time goes by new VCs might be created, some at the same time, others after a period has elapsed and we might have
Where the “copy” number is a “notional” field and is determined by the position of the ‘Items’ entry in the index, which, with duplicates of the same ‘SourceId’, will be governed by the order in which the entry was added to idx_Items_SourceId with new entries being effectively added to the index after the existing entries for a given ‘SourceId’!
When a “copy” is deleted then it vanishes from ‘Items’ and its entry in ‘inx_Items_SourceId’ will also be removed and all copies (‘Items’) will automatically “shuffle up” in that index, i.e. the item is removed from the position in the index as if it never existed!
@Wolfgang I hope the above made it clear that as far as the storage of data is concerned actual copy numbers are not involved and the “rule” to delete the ‘Sources’ entry AND the image is a coding decision made by DxO!
With respect to projects, on Win 10 they are stored in two structures ‘Projects’ which stores an entry containing the name assigned by the user and a (Project)‘Id’ and another structure ‘ProjectsItems’ that has one entry that joins an ‘Items’ entry to a ‘Projects’ entry using the ‘ItemId’ coupled with the '‘ProjectId’ and indexed by two indexes to provide access from ‘Items’ and from ‘Projects’ to the entry. i.e.
In another post someone suggested that deleting items from a project had resulted in loss of the copy entries but according to my tests on Win 10 all that happens is that the ‘ProjectsItems’ Table entry is deleted when you remove an item from a project and that is all!
When you delete a copy from ‘Items’ then the entry in ‘ProjectsItems’ is also removed (verified by my testing) automatically.
Please remember that 'Projects and ‘ProjectsItems’ exist only in the database! No data is held in the DOP that can be used to recreate the project. If you lose the database or deliberately “destroy” it, as I do for testing, then you will lose the Projects data completely.
Hence, regular backups are imperative, as with every system that relies on a database, hence, the prompts from Lightroom, Capture One etc. about “Do you wish to make a backup” etc. as you try to exit!
But all that actually happens is that ‘Items’ entry for VC[1] is deleted and the inx_Items_SourceId entry that corresponds to the now deleted VC[1] entry is removed from the index.
and PL6 refreshes the screen after the VC[1] ‘Remove’ and simply displays what is finds via the index allocating numbers from [1] upwards (+[M] of course), i.e. what was displayed as VC[2] will now be displayed as VC[1], and PL6 amends the DOP accordingly!
So rather than changing anything specifically, PL6 simply deletes the entry as requested and then refreshes the display using what is left! The only thing that actually changes position are the key entries in inx_Items_SourceId to close the gap after the 1 entry (in this case) has been removed!
In fact the display logic doesn’t really need to be “aware” of the nature the change, other than the fact that one has occurred, which triggers it to refresh the screen with whatever it finds in the database, if anything!
PS:- If you went for a “mega” deletion exercise you could wind up with this
@Wolfgang How sad I was hoping to turn you into a database designer !?
In truth the database product I worked with for 36 years, starting just one year after its release (Burroughs/Unisys DMS II) was not an SQL product, so SQL and SQLite are new to me, but the principles are not !
!