@OXiDant I am sorry that your understanding of ‘Projects’ was that what happened in a project stayed in a project.
The Database entries (and therefore the DOP entries, which are “just” external copies of the database entries, and which could well “outlive” the database) are common between the original directory and the ‘Projects’ “directory” a change to any will result in a change to all or rather to the one but that all share.
Absolutely, the Project does not “own” anything except a pointer to the original image data. You can create a VC in a project and you will find it (them) in the DxPL view of the original and they will be added as a new database entry and as an additional element in the one DOP that handles the storage for the [M]aster and any VCs created, regardless of where they were created.
Yes they allow focus, either simply by reducing the number in view or by collecting similar images together for whatever rationale the user wishes to use for creating such a ‘Projects’. Their “cheapness” on storage and processing time are a major asset to their use, particularly with DxPL’s automatic rendering whenever encounters a directory for the first time on any and every subsequent occasion.
If you create VCs in the directory view they can be added to a “Visit to Gothenberg - B/W” ‘Project’ and you can then move to the ‘Project’ to process all the images (VCs) you find their as black and white and the ‘Project’ is doing its job of “restricting” your view, i.e. of focussing your view. When you return to the directory view then both the original image and the B/W VC will be in view.
VCs are relatively “cheap”, they will create additional entries in the database which start out as direct copies of the [M]aster or VC used as the template for the VC at the time the VC was created (in the directory view or in the ‘Project’ view. In addition they will be added to the DOP, effectively at least doubling, then x3, x4 etc. the size of the DOP, depending on how many VCs are created and the complexity of the edits.
To create VCs that can are restricted to a ‘Project’ you could modify DxPL to
(1) create a new image automatically e.g. in a subfolder, add it to the database (and create its external copy - the DOP) and point to it from the ‘Project’
or
(2) add a field in database entry (and in the DOP) indicating that the image (VC) was restricted to the ‘Project’ view, i.e. effectively restricting its visibility any VCs created within a ‘Project’ could only be created in the same project unless you added commands to allow …
The second of the two is way easier to implement but then raises the issue of what do you do if the user decides to delete a ‘Project’ which would be the sole custodian of some (or all) VCs for an image.
The alternative you suggest is complex to implement and each user would potentially want a different variant of the scheme.
Personally I like the idea of ‘Projects’ but don’t like the fact that given I am creating and destroying databases to keep the database simple so that I can review what happens inside DxPL I will keep losing them!
Personally I would leave them as they are but create my own workflow to “emulate” the idea of the ‘Project’ being the sole owner of a VC but push for a utility to allow projects to be backed up.
Such a backup would need to turn the simple references within the ‘Projects’ structures into a table containing the project name and the full identity of the image at the time the ‘Projects’ structures were “dumped” but is complicated by having to reference VCs.
The alternative is to add ‘Project’ references to the DOP but that complicates matters because currently the DOP is a copy of certain database entries for the image copied to a file. Now we need to add additional data although there is an ‘Albums’ field already in the DOP which appear to be unused!
The [M]aster entry:-
The VC1 entry:-
Malfunction by user actions is always a possibility, like hitting “delete” and the wrong folder goes down the drain. I was not developing databases but working with extern referenced files since 1/4 century. Eventually things can go wrong, you’re right.
